Re: Synchronous replication - patch status inquiry

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Synchronous replication - patch status inquiry
Дата
Msg-id AANLkTimFaQO-P3N+yCbSQWHZ_ODvW_Un0=TvWCgT9DAE@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Synchronous replication - patch status inquiry  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: gincostestimate
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: function_name.parameter_name