From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nick Rupley <nickr(at)mirthcorp(dot)com> |
Cc: | nickr(at)mirth(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index |
Date: | 2014-04-30 23:52:48 |
Message-ID: | 10587.1398901968@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Nick Rupley <nickr(at)mirthcorp(dot)com> writes:
> Thanks Tom. We attempted to reindex:
> mirthdb=# reindex index d_mm65_index1;
> ERROR: failed to find parent tuple for heap-only tuple at (14808,2) in
> table "d_mm65"
Ugh :-(. That matches the symptoms of one of the known data-corruption
bugs in 9.3.x, specifically the business about mis-replay of the WAL entry
for locking a tuple. (I suppose this database has either suffered some
crashes, or been promoted from a replication slave?) The bug is fixed as
of 9.3.4, but the fix doesn't magically cure existing corruption :-(
You can look at the specific row involved here with
select * from d_mm65 where ctid = '(14808,2)';
Probably the best recovery strategy is to DELETE that row by ctid,
then reinsert the same data. Lather, rinse, repeat until you can reindex
successfully. Better check your other tables too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | digoal | 2014-05-01 09:09:04 | BUG #10194: Stable function in select clause cann't be optimized to one call? |
Previous Message | Nick Rupley | 2014-04-30 23:39:14 | Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index |