Robert Haas wrote: > On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > >> What I *think* you're saying is that the slave doesn't send per-commit > >> messages, but instead processes the WAL as it's received and then sends > >> a heres-where-I-am status message back upstream immediately before going > >> to sleep waiting for the next chunk. ?That's fine as far as the protocol > >> goes, but I'm not convinced that it really does all that much in terms > >> of improving performance. ?You still have the problem that the master > >> has to fsync its WAL before it can send it to the slave. ?Also, the > >> slave won't know whether it ought to fsync its own WAL before replying. > > > > Yes, apart from last sentence. Please wait for the code. > > So, we're going around and around in circles here because you're > repeatedly refusing to explain how the slave will know WHEN to send > acknowledgments back to the master without knowing which sync rep > level is in use. It seems to be perfectly evident to everyone else > here that there are only two ways for this to work: either the value > is configured on the standby, or there's a registration system on the > master and the master tells the standby its wishes. Instead of asking > the entire community to wait for an unspecified period of time for you > to write code that will handle this in an unspecified way, how about > answering the question? We've wasted far too much time arguing about > this already.
Ideally I would like the sync method to be set on each slave, and have some method for the master to query the sync mode of all the slaves, e.g. appname. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
