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
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index b8f4fe5..9846b9f 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -5403,6 +5403,16 @@ l4:
return HeapTupleMayBeUpdated;
}
+ /*
+ * Also check Xmin: if this tuple was created by an aborted
+ * transaction, we're done.
+ */
+ if (TransactionIdDidAbort(HeapTupleHeaderGetXmin(mytup.t_data)))
+ {
+ UnlockReleaseBuffer(buf);
+ return HeapTupleMayBeUpdated;
+ }
+
old_infomask = mytup.t_data->t_infomask;
old_infomask2 = mytup.t_data->t_infomask2;
xmax = HeapTupleHeaderGetRawXmax(mytup.t_data);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
