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

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

In response to

Responses

Browse pgsql-bugs by date

  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