Re: "caught_up" status in walsender - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: "caught_up" status in walsender
Date
Msg-id AANLkTikBs95qnsl00fsfrEurGXIuY9dvYJEA-ik4GShQ@mail.gmail.com
Whole thread Raw
In response to Re: "caught_up" status in walsender  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "caught_up" status in walsender
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Keepalive for max_standby_delay
Next
From: Fujii Masao
Date:
Subject: Re: Keepalive for max_standby_delay