Re: Transaction-controlled robustness for replication

Simon Riggs wrote:
> > > 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.
> >
> > Oh, so synchronous_commit would not control WAL sync on the slave? What
> > about our fsync parameter? Because the slave is read-only, I saw no
> > disadvantage of setting synchronous_commit to off in postgresql.conf on
> > the slave.
>
> The setting of synchronous_commit will be important if the standby
> becomes the primary. I can see many cases where we might want "syncnet"
> mode (i.e. no fsync of WAL data to disk on standby) and yet want
> synchronous_commit=on when it becomes primary.
>
> So if we were to use same parameters it would be confusing.

I disagree. If they make it the master they change the setting.

Also, if we choose async slave I would expect the consistency of
synchronous_commit rather than fsync=off's database inconsistency.

> > The big problem with an async
> > slave is that not only would you have lost data in a failover, but the
> > database might be inconsistent, like fsync = off, which is something I
> > think we want to try to avoid, which is why I was suggesting
> > synchronous_commit = off.
> >
> > Or were you thinking of always doing fsync on the slave, no matter what.
> > I am worried the slave might not be able to keep up (being
> > single-threaded) and therefore we should allow a way to async commit on
> > the slave.
>
> Bit confused here. I've not said I want always async, neither have I
> said I want always sync.
>
> The main thing is we agree there will be 3 settings, including two
> variants of synchronous replication one fairly safe and one ultra safe.
>
> For the ultra safe mode we really need to see how synch replication will
> work before we comment on where we might introduce fsyncs. I'm presuming
> that incoming WAL will be written to WAL files (and optionally fsynced).
> You might be talking about applying WAL records to the database and then
> fsyncing them, but we do need to allow for crash recovery of the standby
> server, so the data must be synced to WAL files before it is synced to
> database.

I was talking about fsync'ing the WAL when each entry arrives from the
master.

--
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. +