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 3354.1399057710@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index  (Andres Freund <andres@2ndquadrant.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
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-05-02 14:23:50 -0400, Tom Lane wrote:
>> There's been one post-9.3.4 fix in this same general area:
>> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c0bd128c8
>> but according to the commit message, at least, that bug would not have led
>> to the symptom you're seeing, namely rows disappearing from indexes while
>> they're still visible to seqscans.

> Hm. With a bit of bad luck it might. The bug essentially has the
> consequence that two updates might succeed for the same row. Consider
> what happens if the row gets hot updated and then a second hot update,
> due to the bug, also succeeds. The second update will change t_ctid of
> the old tuple to point to the second version. If the transaction that
> did the second update then aborts a index search starting at the root of
> the hot change won't find any surviving tuple. But a seqscan will. :(.

Hm, good point.  Nick, if you're up for applying a hotfix you could try
grabbing the aforesaid patch and seeing if it makes things better.
If not, we're probably gonna need that test case to figure out where
things are still going wrong.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
Next
From: dbaston@gmail.com
Date:
Subject: BUG #10201: Invalid input accepted with IN expression