Re: SELECT FOR UPDATE regression in 9.5

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Jaan-Magnus Tammepuu <magnus(at)voicecom(dot)ee>, Marko Tiikkaja <marko(at)joh(dot)to>
Subject: Re: SELECT FOR UPDATE regression in 9.5
Date: 2016-09-07 17:29:01
Message-ID: 20160907172900.GA134095@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marti Raudsepp wrote:
> Hello list
>
> While testing an application with PostgreSQL 9.5, we experienced an issue
> involving aborted subtransactions and SELECT FOR UPDATE. In certain
> situations, a locking query doesn't return rows that should be visible and
> already locked by the current transaction.

Okay, so the assertion failure is fixed by the attached patch. Also,
the division-by-zero that your test case says shouldn't occur doesn't
occur. But does it solve the larger problem of not returning rows that
should be visible?

Marko, does this fix your reported problem too? Both the assertion and
the overall test case that causes it to fire?

(The problem fixed by the patch is that we were trying to lock tuples
down the update chain, but one of the tuples in the chain had been
updated by an aborted subtransaction. Obviously, there is no point in
locking such a tuple because it effectively "doesn't exist" in the first
place.)

Thanks!

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
aborted-subxact.patch text/x-diff 649 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug Doole 2016-09-07 17:32:35 Re: ICU integration
Previous Message Doug Doole 2016-09-07 17:18:21 Re: ICU integration