Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
Date
Msg-id 10587.1398901968@sss.pgh.pa.us
Whole thread Raw
In response to BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index  (nickr@mirth.com)
Responses Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index  (Nick Rupley <nickr@mirthcorp.com>)
List pgsql-bugs
Nick Rupley <nickr@mirthcorp.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
Next
From: digoal@126.com
Date:
Subject: BUG #10194: Stable function in select clause cann't be optimized to one call?