Re: Fwd: index corruption in PG 8.3.13 - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: Fwd: index corruption in PG 8.3.13
Date
Msg-id AANLkTi=fPsoTmAYeYk9tPhLYUgwWWJqPg4TPV-mcO9dn@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: index corruption in PG 8.3.13  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Responses Re: Fwd: index corruption in PG 8.3.13
Re: Fwd: index corruption in PG 8.3.13
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Next
From: Robert Haas
Date:
Subject: Re: Fwd: index corruption in PG 8.3.13