Re: BUG #7752: FATAL btree error on PITR

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: m(dot)sakrejda(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7752: FATAL btree error on PITR
Date: 2012-12-14 14:04:26
Message-ID: CA+U5nMKaaEYmW1SOt-FmtGLXvnfaWFOZVVavSkGsbt9GC3r6mg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 12 December 2012 01:55, <m(dot)sakrejda(at)gmail(dot)com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7752
> Logged by: Maciek Sakrejda
> Email address: m(dot)sakrejda(at)gmail(dot)com
> PostgreSQL version: 9.1.6
> Operating system: Ubuntu 10.04 LTS 64-bit
> Description:
>
> Ran into the following error in trying to perform a PITR:
>
> FATAL: btree level 66135134 not found in index "436254"
>
> This happened when the PITR was almost complete (judging by on-disk database
> size). I guess this may be related to one of the index corruption issues
> fixed in 9.1.7, but if that's the case, would it perhaps make sense to
> complete the PITR without the corrupt index(es) and deal with the index
> issue separately? Clearly, just a warning is dangerously likely to be
> skipped, but maybe a mechanism like backup_label, that prevents normal
> startup before the issue is resolved?

Yes, I've thought about allowing recovery to skip corrupt indexes, but
that feature hasn't been implemented yet.

We'd need to track such things as recovery proceeds and then mark them
as invalid when recovery completes.

Patches welcome.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-12-14 17:43:53 Re: Bug with temporary child of a permanent table after recovery
Previous Message Heikki Linnakangas 2012-12-14 11:58:13 Bug with temporary child of a permanent table after recovery