On Thu, Aug 26, 2010 at 7:40 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
