On Tue, 2010-09-07 at 12:07 -0400, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs <simon@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.
Every time I explain anything, I get someone run around shouting "but
that can't work!". I'm sorry, but again your logic is poor and the bias
against properly considering viable alternatives is the only thing
perfectly evident. So yes, I agree, it is a waste of time discussing it
until I show working code.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services