On Fri, Aug 27, 2010 at 4:39 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
>> /*
>> * XXX: Should we invent an API to wait for data coming from the
>> * client connection too? It's not critical, but we could then
>> * eliminate the timeout altogether and go to sleep for good.
>> */
>
> Yes, it would be very helpful when walsender waits for the ACK from
> the standby in upcoming synchronous replication.
I propose to change WaitLatch() so that it accepts the socket
descriptor as an argument, to wait for data coming from the
client connection. WaitLatch() monitors not only the self-pipe
but also the given socket. If -1 is supplied, it checks only
the self-pipe.
The socket should be monitored by using poll() if the platform
has it, since poll() is usually more efficient.
So I'd like to change Unix implementation of WaitLatch() as
follows. Thought?
-------------------
define WaitLatch(latch, timeout) WaitLatchAndSocket(latch, -1, timeout)
void WaitLatchAndSocket(Latch *latch, int sock, long timeout);
{
...
FD_SET(selfpipe_readfd, &input_mask);
if (sock != -1)
FD_SET(sock, &input_mask);
#ifdef HAVE_POLL
poll(...)
#else
select(...)
#endif /* HAVE_POLL */
...
}
-------------------
Windows implementation of WaitLatchAndSocket() seems not to be
so simple. We would need to wait for both the latch event and
the packet from the socket by using WaitForMultipleObjectsEx().
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
