Re: Streaming replication status - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Streaming replication status
Date
Msg-id 3f0b79eb1001122110m303fd1bbq4c28dea203bdb9ed@mail.gmail.com
Whole thread Raw
In response to Re: Streaming replication status  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jan 12, 2010 at 10:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> I'm not sure whether poll(2) should be called for this purpose. But
>> poll(2) and select(2) seem to often come together in the existing code.
>> We should follow such custom?
>
> Yes.  poll() is usually more efficient, so it's preferred, but not all
> platforms have it.  (On the other side, I think Windows might have
> only poll and not select.)

OK. I reactivated pq_wait() and secure_poll() which uses poll(2) to
check the socket if available, otherwise select(2).

Also the capability to check the socket for data to be written is not
unused for SR right now (it was provided previously). So I dropped it
for simplification.

http://archives.postgresql.org/pgsql-hackers/2010-01/msg00827.php
> Oh, I think we need to fix that, I'm thinking of doing a select() in the
> loop to check that the socket hasn't been closed yet. I meant we don't
> need to try reading the 'X' to tell apart e.g a network problem from a
> standby that's shut down cleanly.

Without reading the 'X' message from the standby, the walsender doesn't
detect the close of connection immediately in my environment. So I also
reactivated the subset of ProcessStreamMessage().
 git://git.postgresql.org/git/users/fujii/postgres.git branch: replication

Regards,

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


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Streaming replication status
Next
From: Tom Lane
Date:
Subject: Re: lock_timeout GUC patch