On Sun, 2010-05-16 at 00:05 +0300, Heikki Linnakangas 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
8MB at a time still seems like a large batch to me. libpq is going to send it in smaller chunks anyway, so I don't see the importance of trying to keep the batch too large. It just introduces delay into the sending process. We should be sending chunks that matches libpq better. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
