On Mon, Jun 6, 2011 at 5:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> In earlier discussions of how to improve WALInsertLock contention, it
>> was observed that we must zero each new page before we advance the WAL
>> insertion point.
>> http://postgresql.1045698.n5.nabble.com/Reworking-WAL-locking-td1983647.html
>
>> IMHO the page zeroing is completely unnecessary,
>
> I don't believe it's "completely unnecessary". It does in fact offer
> additional protection against mistakenly taking stale data as valid.
> You could maybe argue that the degree of safety increase isn't
> sufficient to warrant the cost of zeroing the page, but you've not
> offered any quantification of either the risk or the cost savings.
If we did ever reference stale data, it would need to have a value of
xl_prev that exactly matched what we expected AND would also need a
CRC that exactly matched also. That would be fairly difficult to
arrange deliberately and pretty close to zero chance of happening
otherwise.
But that even assumes we write the unzeroed data at the end of the
buffer. We don't. We only write data up to the end of the WAL record
on the current page, unless we do a continuation record, which means
only replay we would read in another page and check page headers. So
for this to cause an error, we'd have to have an overall matching CRC,
a matching xl_prev and at least one matching page header, which
contains a pageaddress.
But that even assumes we would read data in a different way to which
it was written.
So the only way we could ever reference the stale data is if the WAL
reading code didn't match the WAL writing code (1) because of a bug or
(2) because of a corrupt pg_control record that caused random access
to an otherwise unreachable part of WAL
AND
the CRC matched, and the xl_prev matched and the next page header matched.
Risk == zero. If it wasn't zero I would even mention it because this
is not a trade-off optimization.
Cost savings are those already identified by yourself in our previous
discussion on this, link given upthread. It's the biggest single
removable item from within WALInsertLock. We can measure them if you
like, but I don't see the value in that. It will clearly be a useful
saving on what we all agree is a heavily contended lock.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
