Re: Fwd: index corruption in PG 8.3.13

From: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fwd: index corruption in PG 8.3.13
Date: 2011-03-16 12:27:31
Message-ID: AANLkTinEbdMUrNoc+_hw7GNdLNDTtx5sVPS2wAgdzqVj@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> Of course, as you mentioned earlier, it's not impossible
> there's a bug in the recovery code.

Yeah, I was looking at the repair_frag function in 8.3.13 (yup it's
ugly!) and found out that the normal ExecInsertIndexTuples call is
used to insert the index entries. That is standard index code used
everywhere. So btree WAL bugs in this code path should be pretty rare
I would think..

> But if an OS crash is involved,
> another possibility is that something went wrong with the fsync -
> maybe there's a lying writeback cache between PG and the platter, for
> example.
>

Yup, plan to re-confirm this too.

Thanks Robert!

Regards,
Nikhils

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-03-16 13:26:29 Re: Fwd: index corruption in PG 8.3.13
Previous Message Robert Haas 2011-03-16 12:24:19 Re: How should the waiting backends behave in sync rep?