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
