Skip site navigation (1) Skip section navigation (2)
PLEASE NOTE: This project is dead. The website is kept online for historical reasons.

Peripheral Links

Header And Logo

| The world's most advanced open source database.

Site Navigation

Testing Postgres-R

Please note that Postgres-R is not ready for productive use.

Also note that all of the information provided here apply to the latest version published and are subject to change.

To simplify testing of Postgres-R it is highly recommended to test on a single machine with multiple instances of Postgres. While that differs substancially from the target scenario, it rules out all network related issues and allows for easier debugging. Also note that EGCS supports this variant exclusively. It does not involve any inter-node communication and thus requires all Postgres-R instances to connect via loopback device.

Data Initialization

At the moment, Postgres-R cannot initialize its nodes automatically, thus you need to manually ensure that all your nodes start with the very same set of data. To do that need to setup a single node first, create a test database and load it with all the data required for your tests. You can then simply copy all of the data directory to your other instances (assuming these are architecturally compatible machines, otherwise you need to dump and restore the data).


Since snapshot 20090702, there are a few important additional GUCs that allow for configuration of Postgres-R. Most importantly replication which enables or disables replication. All of the GCS configuration has moved into a single string to be given to replication_gcs, for example: egcs:port=54320.

The name of the top-most group to use for Postgres-R is configured in replication_group, you should not need to change the default postgres. Last but not least, you now configure seeding of the replicated in postgresql.conf as well. Make very sure you only enable that on exactly one node.

Thus, to continue with the two Postgres instances you have prepared, add the following to their configuration in postgresql.conf:

replication = on
replication_gcs = 'egcs'
You may also want to use different ports on the two instances, so they can start up in parallel. Additionally, you need to allow one of the two to seed the replicated database. Thus, add the following to the first node in addition to the above:
port = 54321
replication_seed = on     # only this node is allowed to seed
                          # the replicated cluster
And for the second append only:
port = 54322
# replication_seed = off  # no seeding from this node


Then start-up EGCS and all your Postgres instances. Please make sure you enable assertions and verbose debugging to be able to check what is going on (options -A1 and -d5 for postmaster). If a Postgres instance has successfully connected to the configured GCS you should see something similar to the following line in the debug log:

DEBUG:  Coordinator: connected to the GCS
After the normal startup phase of Postgres, the recovery or initialization begins. One fine day this will automatically recover crashed nodes and initialize new ones. But at the moment it does pretty much nothing. That's why you needed to provide exact copies to start with manually.

Playing with the replicated database

Your GCS and the Postgres nodes are now ready. Any writing transactions on your test database should now get replicated to the other node. Note that after the initial seeding, all nodes are equal again and allow writing access to the database.

Try simple, concurrent and/or conflicting transactions, etc.. However, please use SERIALIZABLE transaction isolation level and eager replication, as other modes are not supported, yet. Simply issue the following commands to start a transaction:


Enjoy your replicated database.

Project hosted by bluegap | Designed by Ronja Wanner and tinysofa
Copyright © 1996 – 2010 Postgres Global Development Group