Re: Transaction-controlled robustness for replication

On Tue, 2008-08-12 at 12:54 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Tue, 2008-08-12 at 11:51 -0400, Bruce Momjian wrote:
> > > I think you need to make it an enumerated type like log_min_messages;
> > > something like:
> > >
> > > wal_transfer_wait
> >
> > Yeh, that way sounds best and I like name.
> >
> > > with values of:
> > >
> > > nothing: have network traffic send WAL as needed
> > > netflush: wait for flush of WAL network packets to slave
> > > process: wait for slave to process WAL traffic and
> > > optionally fsync
> >
> > Suggest
> > async
> > syncnet
> > syncdisk
>
> I think the first two are fine, but 'syncdisk' might be wrong if the slave
> has 'synchronous_commit = off'. Any ideas?

Yes, synchronous_commit can be set in the postgresql.conf, but its great
advantage is it is a userset parameter.

The main point of the post is that the parameter would be transaction
controlled, so *must* be set in the transaction and thus *must* be set
on the master. Otherwise the capability is not available in the way I am
describing.

synchronous_commit applies to transaction commits. The code path would
be completely different here, so having parameter passed as an info byte
from master will not cause code structure problems or performance
problems.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support