postgres.git / summary / log / commit / refs

commit    1bd148c6aa14dffbb9b21e3db0192b42ea8774a6
Author:   Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:     Fri Aug 02 18:34:56 2013 +0000
First released in: 9.4.0, 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.0

    Fix old visibility bug in HeapTupleSatisfiesDirty
    
    If a tuple is locked but not updated by a concurrent transaction,
    HeapTupleSatisfiesDirty would return that transaction's Xid in xmax,
    causing callers to wait on it, when it is not necessary (in fact, if the
    other transaction had used a multixact instead of a plain Xid to mark
    the tuple, HeapTupleSatisfiesDirty would have behave differently and
    *not* returned the Xmax).
    
    This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998,
    so it's almost 15 years old now.  However, it's hard to see this
    misbehave, because before we had NOWAIT the only consequence of this is
    that transactions would wait for slightly more time than necessary; so
    it's not surprising that this hasn't been reported yet.
    
    Craig Ringer and Andres Freund


 src/backend/utils/time/tqual.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/backend/utils/time/tqual.c b/src/backend/utils/time/tqual.c
index 94e40c69ae8..c0b8970ff81 100644
--- a/src/backend/utils/time/tqual.c
+++ b/src/backend/utils/time/tqual.c
@@ -848,7 +848,8 @@ HeapTupleSatisfiesDirty(HeapTupleHeader tuple, Snapshot snapshot,
 
 	if (TransactionIdIsInProgress(HeapTupleHeaderGetXmax(tuple)))
 	{
-		snapshot->xmax = HeapTupleHeaderGetXmax(tuple);
+		if (!(tuple->t_infomask & HEAP_IS_LOCKED))
+			snapshot->xmax = HeapTupleHeaderGetXmax(tuple);
 		return true;
 	}
 


[parent: b2bdb7b76f47]