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