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

From Tom Lane
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id 18168.1392234917@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Wed, Feb 12, 2014 at 6:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Greg Stark <stark@mit.edu> writes:
>>> This does possibly allocate an extra block past the target block. I'm
>>> not sure how surprising that would be for the rest of the code.

>> Should be fine; we could end up with an extra block after a failed
>> extension operation in any case.

> I know it's fine on the active database, I'm not so clear whether it's
> compatible with the xlog records from the primary. I suppose it'll
> just see an Initialize Page record and happily see the nul block and
> initialize it. It's still a bit scary.

Well, we can easily find uninitialized extra pages on the primary too,
so if WAL replay were unable to cope with that, it would be a bug
regardless.

>> Huh?  Bug in wal-e?  What bug?

> WAL-E actually didn't restore a whole 1GB file due to a transient S3
> problem, in fact a bunch of them.

Hah.  Okay, I think we can write this issue off as closed then.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: issue with gininsert under very high load
Next
From: Stephen Frost
Date:
Subject: Re: issue with gininsert under very high load