Re: Recovery inconsistencies, standby much larger than primary - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id CAM-w4HNeVaWwt3-KVi_OF8MHcO1C0iS50RNKad25He0GTGgKDQ@mail.gmail.com
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 12, 2014 at 8:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Oh, wait a minute.  It's not just a matter of whether we find the right
> block: we also have to consider whether XLogReadBufferExtended will
> apply the right "mode" behavior.  Currently, it supposes that all pages
> past the initially observed EOF should be assumed to be uninitialized;
> but if we're working with an inconsistent database, that seems like
> an unsafe assumption.  It might be that a page is there but we've not
> (yet) fixed the length of some preceding segment.  If we want to not
> get bogus "WAL contains references to invalid pages" failures in such
> scenarios, it seems like we need a more invasive change than what
> I just committed.  I think your patch didn't cover this consideration
> either.

Hm. I *think* those cases would be handled anyways since the table
would later be truncated. Arguably any reference after the "short"
segment is a "reference to an invalid page" since it means it's a
record which predates the records which caused the extension.
Obviously it would still give the error in the case we had where files
were missing but then probably it should give errors in that case.

-- 
greg



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Dead code or buggy code?
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones