Re: Recovery inconsistencies, standby much larger than primary

On Thu, Feb 13, 2014 at 7:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The scenario I could come up with that didn't require a broken base backup
>> was that there was an earlier truncate or vacuum. So the sequence is high
>> offset reference, truncate, growth, crash. All possibly on a single
>> database.
>
> That's not really an issue, because then it would be OK to discard the
> high-offset update; we'd recognize that as safe when we replay the
> truncation.

Yeah, that's my point.

>> It's possible we're better off not assuming we've thought of all possible
>> ways this can happen though.
>
> That's what's bothering me, too.  On the other hand, if we can't think of
> a scenario where it'd be necessary to replay the high-offset update, then
> I'm disinclined to mess with the code further.

And the whole point of the undefined page error checking is to detect
cases like this, so covering them up in the name of possible edge
cases we haven't thought of kind of defeats the purpose. In particular
I would have liked to get errors rather than soldier on when the
database found these missing segments.

In that vein, the other possibly open question was how we got past the
"undefined pages" errors that we did see. Andres said he thought that
was due to the bug where some piece of code was mistakenly using the
presence of a snapshot but I'm not clear how that can cause this
though.


-- 
greg