On 2014-01-13 16:25:48 -0500, Tom Lane wrote:
> > I thought about that approach at first as well, but I am not so sure
> > it's sufficient. Isn't it quite possible that we'd end up reading a page
> > that was *partially* written during a crash and due to that has a
> > corrupted checksum?
>
> If we did, then either the master would also have failed (so we'd not
> be here), or there's a discrepancy between master and slave data,
> in which case we've got bigger problems than this.
If we crashed during replay and then restart replaying it might, at
least without the STANDBY_SNAPSHOT_READY check. I think.
XLOG_BTREE_VACUUM block 10, lastVacuumed 1
XLOG_BTREE_INSERT_SPLIT
XLOG_BTREE_INSERT_LEAF block 5
XLOG_BTREE_VACUUM block 10, lastVacuumed 1
-- crash
if we now restart replaying block 5 can be in just about any state.
... tinker ...
Hm, the standbyMode check isn't sufficient, it's independent from other
consistency checks (like minRecoveryPoint). But we can extend that check
in the redo routine to check for full consistency, which should be fine
since there won't be any relevant pins on buffers before that anyway.
> The addition of a bufmgr function to only return an already-in-cache
> page is a possible future performance enhancement, but I do not care
> for it as a bug fix that has to be back-patched as far as 9.0.
Yea, the only argument I see is that it actually might end up being
simpler, that's why I brought it up.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
