On 07/03/2017 09:39 AM, Heikki Linnakangas wrote: > Hmm. That's not the problem, though. Imagine that instead of the loop > above, you do just: > > WALInsertLockUpdateInsertingAt(CurrPos); > AdvanceXLInsertBuffer(EndPos, false); > > AdvanceXLInsertBuffer() will call XLogWrite(), to flush out any pages > before EndPos, to make room in the wal_buffers for the new pages. Before > doing that, it will call WaitXLogInsertionsToFinish()
Although it's moot in the straightforward approach of re-zeroing in the loop, it would still help my understanding of the system to know if there is some subtlety that would have broken what I proposed earlier, which was an extra flag to AdvanceXLInsertBuffer() that would tell it not only to skip initializing headers, but also to skip the WaitXLogInsertionsToFinish() check ... because I have the entire region reserved and I hold all the writer slots at that moment, it seems safe to assure AdvanceXLInsertBuffer() that there are no outstanding writes to wait for. I suppose it's true there's not much performance to gain; it would save a few pairs of lock operations per empty page to be written, but then, the more empty pages there are at the time of a log switch, the less busy the system is, so the less it matters. -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
