4.2. BDR specific configuration variables

The BDR extension exposes a number of configuration parameters via PostgreSQL's usual configuration mechanism. You can set these in the same way as any other setting, via postgresql.conf or using ALTER SYSTEM. Some variables can also be set per-user, per-database or per-session, but most require a server reload or a full server restart to take effect.

bdr.conflict_logging_include_tuples (boolean)

Log whole tuples when logging BDR tuples. Requires a server reload to take effect.

bdr.log_conflicts_to_table (boolean)

This boolean option controls whether detected BDR conflicts get logged to the bdr.bdr_conflict_history table. See Conflict logging for details. Requires a server reload to take effect.

bdr.synchronous_commit (boolean)

This boolean option controls whether the synchronous_commit setting in BDR apply workers is enabled. It defaults to off. If set to off, BDR apply workers will perform asynchronous commits, allowing PostgreSQL to considerably improve throughput.

It it always is safe to set in the sense that it'll never cause transactions to not be replayed. If it's important that nodes replicate data as soon as possible, so loss of a node causes minimal loss of data that's still only on that node, you should set this to on and configure PostgreSQL's synchronous replication.

Note: Using synchronous commit and synchronous replication will not prevent the apply conflicts that arise with multi-master use of BDR. There is still no locking between nodes and no global snapshot management so concurrent transactions on different nodes can still change the same tuple. See the Overview.

Enabling PostgreSQL's synchronous replication but leaving bdr.synchronous_commit disabled is not generally adviseable. It will noticeably increase the time until a transaction is confirmed to have been replicated. That's because it can only be reported as having safely committed once the WAL is flushed on the receiving side.

bdr.temp_dump_directory (string)

Specifies the path to a temporary storage location, writable by the postgres user, that needs to have enough storage space to contain a complete dump of the a potentially cloned database.

This setting is only used during initial bringup via logical copy. It is not used by bdr_init_copy.

bdr.max_ddl_lock_delay (milliseconds)

Controls how long a DDL lock attempt can wait for concurrent write transactions to commit or roll back before it forcibly aborts them. -1 (the default) uses the value of max_standby_streaming_delay. Can be set with time units like '10s'. See Section 8.1.1.

bdr.ddl_lock_timeout (milliseconds)

Controls how long a DDL lock attempt can wait to acquire the lock. The default value -1 (the default) uses the value of lock_timeout. Can be set with time units like '10s'. See Section 8.1.1. Note that once the DDL lock is acquired and the DDL operation begins this timer stops ticking; it doesn't limit the overall duration a DDL lock may be held, only how long a transaction can wait for one to be acquired. To limit overall duration use a statement_timeout.

bdr.permit_ddl_locking (boolean)

Allow sessions to run DDL commands that acquire the global DDL lock. See DDL replication for details on the DDL lock. Setting this to off by default means that unintended DDL that can be disruptive to production is prevented.

bdr.trace_ddl_locks_level (boolean)

Override the default debug log level for BDR DDL locking (used in DDL replication) so that DDL-lock related messages are emitted at the LOG debug level instead. This can be used to trace DDL locking activity on the system without having to configure the extremely verbose DEBUG1 or DEBUG2 log levels for the whole server.

In increasing order of verbosity, settings are none, statement, acquire_release, peers and debug. At none level DDL lock messages are only emitted at DEBUG1 and lower server log levels. statement adds LOG output whenever a statement causes an attempt to acquire a DDL lock. acquire_release also records when the lock is actually acquired and when it's subsequently released, or if it's declined, and records when peer nodes apply a remote DDL lock. peer adds more detail about the negotiation between peer nodes for DDL locks, and debug forces everything DDL-lock-related to be logged at LOG level.

Changes take effect on server configuration reload, a restart is not required.

See also Monitoring global DDL locks.

4.2.1. Less common or internal configuration variables

bdr.default_apply_delay (integer)

Sets a default apply delay for all configured connections that don't have a explicitly configured apply delay.

This is primarily useful to simulate a high latency network in a low latency testing environment. It requires a server reload to take effect.

bdr.skip_ddl_locking (boolean)

Only affects BDR. Prevents acquisiton of the the global DDL lock when executing DDL statement. This is mainly used internally, but can also be useful in other cases. This option can be set at any time, but only by superusers.

Warning

Inconsiderate usage of this option easily allows to break replication setups.

bdr.permit_unsafe_ddl_commands (boolean)

Only affects BDR. Permits execution of schema changes that cannot safely be replicated. This is primarily used internally, but can also be used in other cases. This option can be set at any time, but only by superusers.

Warning

Inconsiderate usage of this option easily allows to break replication setups.

bdr.skip_ddl_replication (boolean)

Only affects BDR. Skips replication of DDL changes made in a session where this option is set to other systems. This is primarily useful for BDR internal use, but also can be used for some intentional schema changes like adding a index only on some nodes. This option can be set at any time, but only by superusers.

Warning

Inconsiderate usage of this option easily allows to break replication setups.

bdr.do_not_replicate (boolean)

This parameter is intended for internal use only. Changes made in a transaction with this parameter set will not be queued for replication to other nodes.

Warning

Inconsiderate usage of this option easily allows to break replication setups.

bdr.trace_replay (boolean)

When on, emits a log message for each remote action processed by a BDR downstream apply worker. The message records the change type, the table affected, the number of changes since xact start, the xact's commit lsn, commit time, the upstream node and which node it was forwarded from if any. Queued DDL commands and table drops are also printed. The additional logging has a performance impact and should not be enabled when not required.

Changes take effect on server configuration reload, a restart is not required.

Note: Row field contents are not shown. Recompile BDR with VERBOSE_INSERT, VERBOSE_UPDATE and VERBOSE_DELETE defined if you want row values.

bdr.extra_apply_connection_options (boolean)

Add connection parameters to all connections made by BDR nodes to their peers. This is useful for configuring keepalives, SSL modes, etc. Settings given in an individual node's configured connection string will override these options and BDR's built-in connection options. See libpq connection strings.

Note: BDR automatically sets a fallback application name and enables more aggressive keepalives:

connect_timeout=30
keepalives=1
keepalives_idle=20
keepalives_interval=20
keepalives_count=5
         

You may override these settings with this option, e.g.:

bdr.extra_apply_connection_options = 'keepalives=0'

It is not recommended to turn keepalives off unless you are having problems with apply of a large, long running transaction running to completion on an erratic network.

Changes take effect on server configuration reload, a restart is not required.