Now, this situation is apparently expected, because WalSndWaitForWal() does this:
/* * If we're shutting down, trigger pending WAL to be written out, * otherwise we'd possibly end up waiting for WAL that never gets * written, because walwriter has shut down already. */ if (got_STOPPING) XLogBackgroundFlush();
but unfortunately that does not actually do anything, because right at the very beginning XLogBackgroundFlush() does this:
/* back off to last completed page boundary */ WriteRqst.Write -= WriteRqst.Write % XLOG_BLCKSZ;
That is, it intentionally ignores the incomplete page, which means the walsender can't read the record and reach GetFlushRecPtr().
XLogBackgroundFlush() does this since (at least) 2007, so how come we never had issues with this before?
Yeh, not quite what I originally wrote for that.
I think the confusion is that XLogBackgroundFlush() doesn't do quite what it says.
XLogWrite() kinda does with its "flexible" parameter. So I suggest we do the same on XLogBackgroundFlush() so callers can indicate whether they want it to be flexible or not.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
