From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Subject: | Re: Recovery inconsistencies, standby much larger than primary |
Date: | 2014-02-12 19:55:17 |
Message-ID: | 18168.1392234917@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On Wed, Feb 12, 2014 at 6:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Greg Stark <stark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-02-12 20:06:35 | Re: issue with gininsert under very high load |
Previous Message | Andres Freund | 2014-02-12 19:50:46 | Re: issue with gininsert under very high load |