Обсуждение: BUG #7752: FATAL btree error on PITR

Поиск
Список
Период
Сортировка

BUG #7752: FATAL btree error on PITR

От
m.sakrejda@gmail.com
Дата:
The following bug has been logged on the website:

Bug reference:      7752
Logged by:          Maciek Sakrejda
Email address:      m.sakrejda@gmail.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?

Re: BUG #7752: FATAL btree error on PITR

От
Simon Riggs
Дата:
On 12 December 2012 01:55,  <m.sakrejda@gmail.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference:      7752
> Logged by:          Maciek Sakrejda
> Email address:      m.sakrejda@gmail.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