Re: Synchronous replication - patch status inquiry - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Synchronous replication - patch status inquiry
Date
Msg-id AANLkTimFaQO-P3N+yCbSQWHZ_ODvW_Un0=TvWCgT9DAE@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Synchronous replication - patch status inquiry  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: gincostestimate
Next
From: "David E. Wheeler"
Date:
Subject: function_name.parameter_name