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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers