On Sun, May 16, 2010 at 6:05 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> WALSender sleeps even when it might have more WAL to send, it doesn't >>> check it just unconditionally sleeps. At least WALReceiver loops until >>> it has no more to receive. I just can't imagine why that's useful >>> behaviour. >> >> Good catch. That should be fixed. >> >> I also note that walsender doesn't respond to signals, while it's >> sending a large batch. That's analogous to the issue that was addressed >> recently in the archiver process. > > Attached patch rearranges the walsender loops slightly to fix the above. > XLogSend() now only sends up to MAX_SEND_SIZE bytes (== XLOG_SEG_SIZE / > 2) in one round and returns to the main loop after that even if there's > unsent WAL, and the main loop no longer sleeps if there's unsent WAL. > That way the main loop gets to respond to signals quickly, and we also > get to update the shared memory status and PS display more often when > there's a lot of catching up to do. > > Comments
The main loop needs to respond to also the 'X' message from the standby quickly? 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
