Re: "caught_up" status in walsender

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: "caught_up" status in walsender
Дата
Msg-id AANLkTikBs95qnsl00fsfrEurGXIuY9dvYJEA-ik4GShQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: "caught_up" status in walsender  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "caught_up" status in walsender  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 02/06/10 21:44, Tom Lane wrote:
>>> In the current coding, the effect of not setting *caughtup here is just
>>> that we uselessly call XLogSend an extra time for each transmission
>>> (because the main loop won't ever delay immediately after a
>>> transmission).  But without this, we'd never send caughtup = true
>>> to the slave.
>
>> That's intentional. It could take some time for the WAL to be sent, if
>> the network is busy, so by the time XLogSend returns you might well not
>> be caught up anymore.
>
> It may have been intentional, but it's still wrong.  If you were able to
> pull all of WAL into the record-to-be-sent, you should sleep afterwards,
> not send an extra record containing a few more bytes.

For reducing the workload of walsender?

This seems OK in 9.0 since only asynchronous replication is supported.
But when we'll implement synchronous replication in the future, we
might have to revert that change. Since a transaction commit might wait
for such an extra record to be replicated, walsender should aggressively
send all sendable WAL.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Keepalive for max_standby_delay
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Keepalive for max_standby_delay