Re: Transaction-controlled robustness for replication

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?

> > The 'process' option either waits for fsync on the slave or not
> > depending on how the slave is configured, meaning you could use
> > synchronous_commit off to not wait for the fsync to disk.
>
> Hmmm, not sure that flicking a switch on the standby should cause a loss
> of performance on the master. That will be an accident waiting to
> happen. Best to make all things that effect the performance/robustness
> of the master be configuration options on the master side.

Well, we are not removing synchronous_commit so a slave certainly could
be configured to be async, so I don't see that making the master set this
makes any sense, unless you want the master to somehow override that.

So, I think there are three options, async, syncnet, and perhaps
'commit', meaning the slave committed the transactions. That can be
sync slave or async slave, based on the configuration of the slave.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +