pgsql: Avoid resetting Xmax when it's a multi with an aborted update - Mailing list pgsql-committers

From Alvaro Herrera
Subject pgsql: Avoid resetting Xmax when it's a multi with an aborted update
Date
Msg-id E1VobQw-0006wN-5A@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Avoid resetting Xmax when it's a multi with an aborted update

HeapTupleSatisfiesUpdate can very easily "forget" tuple locks while
checking the contents of a multixact and finding it contains an aborted
update, by setting the HEAP_XMAX_INVALID bit.  This would lead to
concurrent transactions not noticing any previous locks held by
transactions that might still be running, and thus being able to acquire
subsequent locks they wouldn't be normally able to acquire.

This bug was introduced in commit 1ce150b7bb; backpatch this fix to 9.3,
like that commit.

This change reverts the change to the delete-abort-savept isolation test
in 1ce150b7bb, because that behavior change was caused by this bug.

Noticed by Andres Freund while investigating a different issue reported
by Noah Misch.

Branch
------
REL9_3_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/c6cd27e36b9c58ceda8582ba81e37b6f9ad87d59

Modified Files
--------------
src/backend/utils/time/tqual.c                     |   21 ++++++++++++++++----
.../isolation/expected/delete-abort-savept.out     |   13 +++++-------
2 files changed, 22 insertions(+), 12 deletions(-)


pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: pgsql: build: pass EXTRA_REGRESS_OPTS to secondary regression tests
Next
From: Alvaro Herrera
Date:
Subject: pgsql: Avoid resetting Xmax when it's a multi with an aborted update