On Wed, 1 May 2019 at 01:28, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote:
> 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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
