BDR Function Reference

From PostgreSQL wiki

Jump to: navigation, search

This document is obsolete. See the official BDR documentation for current information.

BDR adds a number of functions. Some of them have been integrated into PostgreSQL 9.4 and can be found in the 9.4 documentation. Others are pending integration; those are listed here.



pg_get_transaction_committime(txid integer): Get the timestamp at which the specified transaction, as identified by transaction ID, committed. This function can be useful when monitoring replication lag.

This function is added by the commit timestamp patch set and is included in the bdr branch.


The pg_xlog_wait_remote_apply(lsn text, pid integer) function allows you to wait on an upstream master until all downstream masters' replication has caught up to a certain point.

The lsn argument is a Log Sequence Number, an identifier for the WAL (Write-Ahead Log) record you want to make sure has been applied on all nodes. The most useful record you will want to wait for is pg_current_xlog_location(), as discussed in PostgreSQL Admin Functions in the manual.

The pid argument specifies the process ID of a walsender to wait for. It may be set to zero to wait until the receivers associated with all walsenders on this upstream master have caught up to the specified lsn, or to a process ID obtained from to wait for just one downstream to catch up.

The most common use is:

 select pg_xlog_wait_remote_apply(pg_current_xlog_location(), 0)

which will wait until all downstream masters have applied changes up to the time on the upstream master at which pg_xlog_wait_remote_apply was called.

pg_current_xlog_location is not transactional, so unlike things like current_timestamp it'll always return the very latest status server-wide, irrespective of how long the current transaction has been running for and when it started.


pg_xlog_wait_remote_receive is the same as pg_xlog_wait_remote_apply, except that it only waits until the remote node has confirmed that it's received the given LSN, not until it has actually applied it after receiving it.


The bdr_apply_pause() function allows you to temporarily stop the application of changes from upstream masters. Running:

   select bdr_apply_pause()

will pause until the bdr_apply_resume() function is executed.


The bdr_apply_resume() function resumes application of changes after it has been paused by bdr_apply_pause().

Personal tools