Default expectation safe interface. Equivalent to

with = withConfig defaultConfig

Since: 1.21.0.0

Exception safe database create with options. See startConfig for more details. Calls stop even in the face of exceptions.

Since: 1.21.0.0

Exception safe version of restart.

Since: 1.12.0.0

The default configuration. This will create a database called "postgres" via initdb (it's default behavior). It will create a temporary directory for the data and a temporary directory for a unix socket and listen on 127.0.0.1 and ::1 on a random port. Additionally it will use the following "postgresql.conf" which is optimized for performance.

shared_buffers = 12MB
fsync = off
synchronous_commit = off
full_page_writes = off
log_min_messages = PANIC
log_min_error_statement = PANIC
log_statement = none
client_min_messages = ERROR
commit_delay = 100000
wal_level = minimal
archive_mode = off
max_wal_senders = 0

defaultConfig also passes the --no-sync flag to initdb.

If you would like to customize this behavior you can start with the defaultConfig and overwrite fields or combine a defaultConfig with another Config using <> (mappend).

Alternatively you can eschew defaultConfig altogether, however your postgres might start and run faster if you use defaultConfig.

The defaultConfig redirects all output to /dev/null. See verboseConfig for a version that logs more output.

To append additional lines to "postgresql.conf" file create a custom Config like the following.

custom = defaultConfig <> mempty
  { postgresConfigFile =
      [ ("wal_level, "replica")
      , ("archive_mode", on")
      , ("max_wal_senders", "2")
      , ("fsync", "on")
      , ("synchronous_commit", "on")
      ]
  }

As an alternative to using defaultConfig one could create a config from connections parameters using optionsToDefaultConfig.

Since: 1.21.0.0

Default configuration for PostgreSQL versions 9.3 and greater but less than 10.

If you get an error that "--no-sync" is an invalid parameter then you should use this config.

Since: 1.21.1.0

This is similar to defaultConfig but it logs as much as possible..

Since: 1.21.0.0

A config which loads and configures auto_explain. Useful for understanding slow queries plans.

Since: 1.34.1.0

Attempt to create a Config from a Options. Useful if you want to create a database owned by a specific user you will also login with among other use cases.

Since: 1.21.0.0

Handle for holding temporary resources, the postgres process handle and postgres connection information. The DB also includes the final plan used to start initdb, createdb and postgres.

Since: 1.12.0.0

Convert a DB to a connection string. Alternatively one can access the Options using toConnectionOptions.

Since: 1.12.0.0

Convert a DB to a connection Options type.

Since: 1.12.0.0

Access the data directory. This was either generated or specified explicitly when creating the Config

Since: 1.12.0.0

Get the directory that is used to create other temporary directories

Since: 1.12.0.0

Get the final postgresql.conf

Since: 1.25.0.0

Make the data directory permanent. Useful for debugging. If you are using with or withConfig this function will not modify the DB that is passed for cleanup. You will need to setup your own bracket like

bracket (fmap makeDataDirectoryPermanent start) (either mempty stop)

Since: 1.24.0.0

Display a DB.

Since: 1.12.0.0

Default start behavior. Equivalent to calling startConfig with the defaultConfig.

Since: 1.21.0.0

Create zero or more temporary resources and use them to make a Config.

The passed in config is inspected and a generated config is created. The final config is built by

generated <> extra

Based on the value of socketDirectory a "postgresql.conf" is created with:

listen_addresses = '127.0.0.1, ::1'
unix_socket_directories = 'SOCKET_DIRECTORY'

Additionally the generated Config also:

• Sets a connectionTimeout of one minute.
• Redirects output to /dev/null.

All of these values can be overrided by the extra config.

The returned DB requires cleanup. startConfig should be used with a bracket and stop, e.g.

withConfig :: Config -> (DB -> IO a) -> IO (Either StartError a)
withConfig plan f = bracket (startConfig plan) (either mempty stop) $
  either (pure . Left) (fmap Right . f)

or just use withConfig. If you are calling startConfig you probably want withConfig anyway.

Since: 1.15.0.0

Stop the postgres process and cleanup any temporary resources that might have been created.

Since: 1.12.0.0

Restart the postgres from DB using the prior Config. This will also start an instance previously stoppped with stopPostgres.

Since: 1.12.0.0

Only stop the postgres process but leave any temporary resources. Useful for testing backup strategies when used in conjunction with restart or withRestart.

Since: 1.12.0.0

Equivalent to withDbCacheConfig with the CacheConfig defaultCacheConfig makes.

Here is an example using caching:

withDbCache $ \cache -> do
  withConfig (cacheConfig cache) $ \db -> ...
  withConfig (cacheConfig cache) $ \db -> ...

Since: 1.25.0.0

Enable initdb data directory caching. This can lead to a 4x speedup.

Exception safe version of setupInitDbCache. Equivalent to

withDbCacheConfig = bracket (setupInitDbCache config) cleanupInitDbCache

Since: 1.25.0.0

Configuration for the initdb data directory cache.

Since: 1.25.0.0

defaultCacheConfig attempts to determine if the cp on the path supports "copy on write" flags and if it does, sets cacheUseCopyOnWrite to True.

It sets cacheDirectoryType to Permanent ~/.tmp-postgres and cacheTemporaryDirectory to /tmp (but this is not used when Permanent is set).

Since: 1.25.0.0

A handle to cache temporary resources and configuration.

Since: 1.25.0.0

Helper to make a Config out of caching info.

Since: 1.25.0.0

Setup the initdb cache folder.

Since: 1.25.0.0

Cleanup the cache directory if it was Temporary.

Since: 1.25.0.0

Exception safe method for taking a file system level copy of the database cluster.

Snapshots are useful if you would like to start every test from a migrated database and the migration process is more time consuming then copying the additional data.

Here is an example with caching and snapshots:

withDbCache $ \cache -> withConfig (cacheConfig cache) $ \db ->
  migrate db
  withSnapshot Temporary db $ \snapshot -> do
    withConfig (snapshotConfig db) $ \migratedDb -> ...
    withConfig (snapshotConfig db) $ \migratedDb -> ...
    withConfig (snapshotConfig db) $ \migratedDb -> ...

The Snapshots are ephemeral. If you would like the Snapshots to persistent consider using cacheAction instead.

Since: 1.29.0.0

A type to track a possibly temporary snapshot directory

Since: 1.20.0.0

Convert a snapshot into a Config that includes a copyConfig for copying the snapshot directory to a temporary directory.

Since: 1.20.0.0

Shutdown the database and copy the directory to a folder.

Since: 1.29.0.0

Cleanup any temporary resources used for the snapshot.

Since: 1.20.0.0

Check to see if a cached data directory exists.

If the file path does not exist the initial config is used to start a postgres instance. After which the action is applied, the data directory is cached and postgres is shutdown.

cacheAction mappends a config to copy the cached data directory on startup onto the initial config and returns it. In other words:

initialConfig <> configFromCachePath

cacheAction can be used to create a snapshot of migrated database and not remigrate as long as the migration does not change. See withSnapshot for a ephemeral version of taking snapshots.

You can nest calls to cacheAction and safe to call it from several threads. However cacheAction uses locks internal to prevent multiple threads from stomping on each other.

If one makes a nested call and accidently uses the same cache directory in both calls the calls will deadlock. If this occurs on the same thread RTS will throw an exception. However do not rely on this and just be careful to not reuse the same cache path when nesting calls.

There is no good reuse the cache path when nesting so one is unlikely to run into this.

Since: 1.34.0.0

A list of failures that can occur when starting. This is not and exhaustive list but covers the errors that the system catches for the user.

Since: 1.29.0.0

The high level options for overriding default behavior.

Since: 1.22.0.0

Display a Config.

Since: 1.12.0.0

Process configuration

Since: 1.12.0.0

The environment variables can be declared to inherit from the running process or they can be specifically added.

Since: 1.12.0.0

A type to help combine command line Args.

Since: 1.12.0.0

Used to specify a Temporary folder that is automatically cleaned up or a Permanent folder which is not automatically cleaned up.

Since: 1.12.0.0

A type to track whether a file is temporary and needs to be cleaned up.

Since: 1.12.0.0

Accum is a monoid.

It's <> behavior is analogous to 1 and 0 with *. Think of DontCare as 1 and Zlich as 0.

The behavior of Merge is like Justs.

Since: 1.17.0.0

A way to log internal Events

Since: 1.12.0.0

Internal events for debugging

Since: 1.12.0.0