Simon Riggs wrote: > > > > 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.
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. > 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. OK, I was just trying to simplify it. 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. Certainly if the master is async sending the data, there is no need to do a synchronous_commit on the slave. -- 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
