Re: Recovery inconsistencies, standby much larger than primary

From: Andrea Suisani <sickpig(at)opinioni(dot)net>
To: Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>
Subject: Re: Recovery inconsistencies, standby much larger than primary
Date: 2014-02-13 08:36:09
Message-ID: 52FC83F9.2000300@opinioni.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

On 02/12/2014 08:27 PM, Greg Stark wrote:
> 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:
>>> For what it's worth I've confirmed the bug in wal-e caused the initial
>>> problem.
>>
>> 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. It's remarkable that Postgres kept
> going with that much data missing. But the arithmetic worked out on
> the case I checked it on, which was the last one that I just sent the
> xlog record for last night. In that case there was precisely one
> segment missing and the relation was extended by the number of
> segments you would expect if it filled in that missing segment and
> then jumped to the end of the relation.

sorry for interrupting, but did we already notify wal-e's maintainer?

Andrea

ps cc:ed Daniel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message amul sul 2014-02-13 08:59:39 how set GUC_check_errhint_string in call_string_check_hook()
Previous Message Heikki Linnakangas 2014-02-13 08:11:22 Re: [BUG] Archive recovery failure on 9.3+.