Skip site navigation (1) Skip section navigation (2)

Review: Patch for Synchronous Replication

From: Thom Brown <thom(at)linux(dot)com>
To: pgsql-rrreviewers(at)postgresql(dot)org
Subject: Review: Patch for Synchronous Replication
Date: 2010-09-29 22:29:24
Message-ID: (view raw or whole thread)
Lists: pgsql-hackerspgsql-rrreviewers
This is a basic review of Fujii Masao's synchronous replication patch

Review Description
This patch extends existing asynchronous streaming replication with
options to enable different levels of synchronous behaviour.  On the
primary, the is a new standbys.conf file containing a manifest of
standbys it seeks a form a confirmation from before committing
transactions.  These contain standby name, level of synchronicity (if
it wasn't a word, it is now), and a timeout value specifying how long
the primary is willing to wait for confirmation before aborting the
transaction.  On the standby, the new option "standby_name" has been
added to publish a named identity of the standby server to the

Patch application
The patch applies cleanly to HEAD.  All regression tests pass
successfully as expected.

I configured the primary's standby.conf to provide synchronous
replication to a single slave using fsync as it's replication level
and a timeout of 100ms.  The wal_level was set to hot_standby in
postgresql.conf.  The standby's recovery.conf had its standby_name
value set to match that expected by the primary's standby.conf.  This
is summarised as follows:

## primary postgresql.conf:
wal_level = hot_standby
max_wal_senders = 2
wal_keep_segments = 2

## primary standbys.conf
cougar            fsync           100ms

## primary pg_hba.conf
# TYPE  DATABASE        USER            CIDR-ADDRESS            METHOD
host    replication     postgres       trust

## standby postgresql.conf
hot_standby = on

## standby recovery.conf
standby_name = 'cougar'
standby_mode = 'on'
primary_conninfo = 'host= port=5432'


The primary started up fine and was accepting connections.  A base
backup was taken for the standby, and after configuring the standby, I
attempted to bring it up, but received the following error:

postgres(at)cougar:~/project/data$ pg_ctl start
server starting
postgres(at)cougar:~/project/data$ LOG:  database system was shut down in
recovery at 2010-09-29 22:52:24 BST
LOG:  entering standby mode
LOG:  redo starts at 0/1000020
LOG:  record with zero length at 0/10000B0
FATAL:  could not connect to the primary server: invalid connection
option "standby_name"

I believe I am using the correct parameter as I followed the
additional documentation provided in the patch.


It at least appears to me that it isn't functional in its current
state, or there is setup information missing from the
documentation.... or I've make a stupid mistake somewhere (likely).

Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935


pgsql-hackers by date

Next:From: Thom BrownDate: 2010-09-29 22:57:33
Subject: Re: Review: Patch for Synchronous Replication
Previous:From: Kevin GrittnerDate: 2010-09-29 21:45:11
Subject: Re: Using streaming replication as log archiving

pgsql-rrreviewers by date

Next:From: Thom BrownDate: 2010-09-29 22:57:33
Subject: Re: Review: Patch for Synchronous Replication
Previous:From: Marko TiikkajaDate: 2010-09-29 19:14:07
Subject: Re: [HACKERS] top-level DML under CTEs

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group