Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Date
Msg-id fe79f7c5-2bc5-f763-8908-78675ba33eba@anastigmatix.net
Whole thread Raw
In response to Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Request more documentation for incompatibility ofparallelism and plpgsql exec_run_select
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Race conditions with WAL sender PID lookups