On Tue, Sep 14, 2010 at 5:51 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 14/09/10 05:02, Fujii Masao wrote: >> >> + /* >> + * Walreceiver sets this latch every time new WAL has been >> received and >> + * fsync'd to disk, allowing startup process to wait for new WAL >> to >> + * arrive. >> + */ >> + Latch receivedLatch; >> >> I think that this latch should be available for other than walreceiver - >> startup process communication. For example, backend - startup process >> communication, which can be used for requesting a failover via SQL >> function >> by users in the future. What about putting the latch in XLogCtl instead of >> WalRcv and calling OwnLatch at the beginning of the startup process >> instead >> of RequestXLogStreaming? > > Yes, good point. I updated the patch along those lines, attached.
Looks good. + /* + * Take ownership of the wakup latch if we're going to sleep during + * recovery. + */ + if (StandbyMode) + OwnLatch(&XLogCtl->recoveryWakeupLatch); Since automatic restart after backend crash always performs a normal crash recovery, the startup process will never call OwnLatch more than once. So there might be no harm even if the startup process doesn't disown the shared latch. But... what about calling DisownLatch at the end of recovery just in case? 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
