Re: WALInsertLock tuning

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 07.06.2011 10:55, Simon Riggs wrote:
>> How would that help?

> It doesn't matter whether the pages are zeroed while they sit in memory.
> And if you write a full page of WAL data, any wasted bytes at the end of
> the page don't matter, because they're ignored at replay anyway. The
> possibility of mistaking random garbage for valid WAL only occurs when
> we write a partial WAL page to disk. So, it is enough to zero the
> remainder of the partial WAL page (or just the next few words) when we
> write it out.

> That's a lot cheaper than fully zeroing every page. (except for the fact
> that you'd need to hold WALInsertLock while you do it)

I think avoiding the need to hold both locks at once is probably exactly
why the zeroing was done where it is.

An interesting alternative is to have XLogInsert itself just plop down a
few more zeroes immediately after the record it's inserted, before it
releases WALInsertLock. This will be redundant work once the next
record gets added, but it's cheap enough to not matter IMO. As was
mentioned upthread, zeroing out the bytes that will eventually hold the
next record's xl_prev field ought to be enough to maintain a guarantee
that we won't believe the next record is valid.

regards, tom lane