Re: Fwd: index corruption in PG 8.3.13

Поиск
Список
Период
Сортировка
От Nikhil Sontakke
Тема Re: Fwd: index corruption in PG 8.3.13
Дата
Msg-id AANLkTi=fPsoTmAYeYk9tPhLYUgwWWJqPg4TPV-mcO9dn@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fwd: index corruption in PG 8.3.13  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Ответы Re: Fwd: index corruption in PG 8.3.13  (Robert Haas <robertmhaas@gmail.com>)
Re: Fwd: index corruption in PG 8.3.13  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Hi,

> To summarize, as I see it - the zeroed out block 523 should have been
> the second left-most leaf and should have pointed out to 522. Thus
> re-establishing the index chain
>
> 524 -> 523 -> 522 -> 277 -> ...
>
>> Was there a machine restart in the picture as well?
>

It seems there might have been a machine restart involved too. So I
guess even WAL writing could have been impacted.

But even if VF was ongoing at the time of restart, the WAL replay on
restart should not do anything since this will be a non-committed
transaction?

Also I was looking at ReadRecord and saw that it logs a message for
failed CRC blocks but the WAL replay just stops at that point since it
returns a NULL. Is there a way to find out if more blocks follow in
the wake of this failed block (should be a matter of calling
ReadRecord with NULL as a first argument I think)? If so maybe we can
warn further that error was encountered in the middle of WAL replay.
However the last block too could be CRC check-fail candidate...

BTW, is there a possibility to encounter trailing blocks with CRC
failures regularly? For transactions that were ongoing at the time of
shutdown and did not get a chance to commit or WAL log properly?

Regards,
Nikhils


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Fwd: index corruption in PG 8.3.13