From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transaction-controlled robustness for replication |
Date: | 2008-08-12 17:33:05 |
Message-ID: | 200808121733.m7CHX5d15872@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-08-12 17:34:39 | Re: Uncopied parameters on CREATE TABLE LIKE |
Previous Message | Simon Riggs | 2008-08-12 17:32:32 | Re: Transaction-controlled robustness for replication |