Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

On Thu, Aug 26, 2010 at 7:40 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Here's a first attempt at implementing that. To demonstrate how it works, I
> modified walsender to use the new latch facility, also to respond quickly to
> SIGHUP and SIGTERM.

Great!

> There's two kinds of latches, local and global. Local latches can only be
> set from the same process - allowing you to replace pg_usleep() with
> something that is always interruptible by signals (by setting the latch in
> the signal handler). The global latches work the same, and indeed the
> implementation is the same, but the latch resides in shared memory, and can
> be set by any process attached to shared memory. On Unix, when you set a
> latch waited for by another process, the setter sends SIGUSR1 to the waiting
> process, and the signal handler sends the byte to the self-pipe to wake up
> the select().

According to this explanation, the latch which walsender uses seems to be
local. If it's true, walsender should call InitSharedLatch rather than
InitLatch?

> /*
> * 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.

Regards,

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