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
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 |