pgsql: Avoid resetting Xmax when it's a multi with an aborted update
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
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/07aeb1fec571920839822c11851d38ef48952d6c
Modified Files
--------------
src/backend/utils/time/tqual.c | 21 ++++++++++++++++----
.../isolation/expected/delete-abort-savept.out | 13 +++++-------
2 files changed, 22 insertions(+), 12 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Avoid resetting Xmax when it's a multi with an aborted update
I may be confused, but this patch doesn't look like it does what
your commit log message says. It looks to me like the logic for
setting the hint bit is exactly the same as before; what's changed
is only the return code from HeapTupleSatisfiesUpdate.
The code looks right, though. Is it just that your commit message
misdescribes it?
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tom Lane wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Avoid resetting Xmax when it's a multi with an aborted update
I may be confused, but this patch doesn't look like it does what
your commit log message says. It looks to me like the logic for
setting the hint bit is exactly the same as before; what's changed
is only the return code from HeapTupleSatisfiesUpdate.The code looks right, though. Is it just that your commit message
misdescribes it?
You're right, I got the commit message wrong. The problem is still that
locks can go "ignored" (if not "forgotten") due to the wrong return
code.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers