Re: Transaction-controlled robustness for replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Transaction-controlled robustness for replication
Date
Msg-id 1218562352.5343.101.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Transaction-controlled robustness for replication  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Transaction-controlled robustness for replication  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Transaction-controlled robustness for replication
Next
From: Magnus Hagander
Date:
Subject: Re: temporary statistics option at initdb time