Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
As regards the zero_damaged_pages question, I raised that some time ago
but we didn't arrive at an explicit answer. All I would say is we can't
allow invalid pages in the buffer manager at any time, whatever options
we have requested, otherwise other code will fail almost immediately.
Yeah --- the proposed new bufmgr routine should probably explicitly zero
the content of the buffer. It doesn't really matter in the context of
WAL recovery, since there can't be any concurrent access to the buffer,
but it'd make it safe to use in non-WAL contexts (I think there are
other places where we know we are going to init the page and so a
physical read is a waste of time).
Is there? I can't think of any. Extending a relation doesn't count.
Zeroing the buffer explicitly might be a good idea anyway. I agree it
feels a bit dangerous to have a moment when there's a garbled page in
buffer cache, even if only in recovery.
Also, this would let the patch be
+ if (alloc_only)
+ MemSet...
+ else
smgrread...
and you don't need to hack out the PageHeaderIsValid test, since it will
allow zeroed pages.
Well, I'd still put the PageHeaderIsValid test in the else-branch. Not
like the few cycles spent on the test matter, but I don't see a reason
not to.
Possibly ReadZeroedBuffer would be a better name?
Yeah, sounds good. "Read" is a bit misleading, since it doesn't actually
read in the buffer, but it's good that the name is closely related to
ReadBuffer.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly