This page in other versions: 0.9 / 1.0 / 1.0.3

4.2. BDR/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/UDR 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.

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_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.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.