S=C3=A9kine Coulibaly <scoulibaly@gmail.com> wrote:
> I indeed want the security brought by synchronous replication.
> Having a commit no to return as long as the replica is not
> up-and-streaming is what I expect and perfectly fits my needs. It
> is perfectly right in my use case for the master to wait for the
> replica as long as necessary. Asynchronous replication is
> definitely not what I want.
>
> My concern here is that, although the slave is back, the pending
> commit is not performed on the master side.
I apologize for misunderstanding what you were experiencing.
> I'd expect all ongoing and blocking commits to be unblocked as
> soon as the slave pops in.
Indeed they should.
> Since the master and slave are synchronous after the slave is
> back, what's the point in holding a transaction forever in the
> master's backend ?
I know that a number of bugs for this sort of edge condition have
been fixed since 9.2.4 was release (on 2013-04-04). I strongly
recommend that you apply the latest bug-fix roll-up for the 9.2
branch, which is currently 9.2.10.
http://www.postgresql.org/support/versioning/
If you still see such behavior with the most recently released bug
fixes, please post again, attaching the configuration files and
showing log entries (from both clusters) from around the time the
slave is brought up.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company