postgres.git / summary / log / commit / refs

commit    293ec33c32e8e20fcb5859885a4b37ff6d855240
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Wed Apr 18 15:50:45 2012 +0000

    Remove bogus comment from HeapTupleSatisfiesNow.
    
    This has been wrong for a really long time.  We don't use two-phase
    locking to protect against serialization anomalies.
    
    Per discussion on pgsql-hackers about 2011-03-07; original report
    by Dan Ports.


 src/backend/utils/time/tqual.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/src/backend/utils/time/tqual.c b/src/backend/utils/time/tqual.c
index 31791a744f1..c1c78c389cb 100644
--- a/src/backend/utils/time/tqual.c
+++ b/src/backend/utils/time/tqual.c
@@ -323,16 +323,6 @@ HeapTupleSatisfiesSelf(HeapTupleHeader tuple, Snapshot snapshot, Buffer buffer)
  *		 (Xmax != my-transaction &&			the row was deleted by another transaction
  *		  Xmax is not committed))))			that has not been committed
  *
- *		mao says 17 march 1993:  the tests in this routine are correct;
- *		if you think they're not, you're wrong, and you should think
- *		about it again.  i know, it happened to me.  we don't need to
- *		check commit time against the start time of this transaction
- *		because 2ph locking protects us from doing the wrong thing.
- *		if you mess around here, you'll break serializability.  the only
- *		problem with this code is that it does the wrong thing for system
- *		catalog updates, because the catalogs aren't subject to 2ph, so
- *		the serializability guarantees we provide don't extend to xacts
- *		that do catalog accesses.  this is unfortunate, but not critical.
  */
 bool
 HeapTupleSatisfiesNow(HeapTupleHeader tuple, Snapshot snapshot, Buffer buffer)


[parent: 4a6fab03f23e]