Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 293ec33

Browse files
committed
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.
1 parent 4a6fab0 commit 293ec33

File tree

1 file changed

+0
-10
lines changed

1 file changed

+0
-10
lines changed

src/backend/utils/time/tqual.c

-10
Original file line numberDiff line numberDiff line change
@@ -323,16 +323,6 @@ HeapTupleSatisfiesSelf(HeapTupleHeader tuple, Snapshot snapshot, Buffer buffer)
323323
* (Xmax != my-transaction && the row was deleted by another transaction
324324
* Xmax is not committed)))) that has not been committed
325325
*
326-
* mao says 17 march 1993: the tests in this routine are correct;
327-
* if you think they're not, you're wrong, and you should think
328-
* about it again. i know, it happened to me. we don't need to
329-
* check commit time against the start time of this transaction
330-
* because 2ph locking protects us from doing the wrong thing.
331-
* if you mess around here, you'll break serializability. the only
332-
* problem with this code is that it does the wrong thing for system
333-
* catalog updates, because the catalogs aren't subject to 2ph, so
334-
* the serializability guarantees we provide don't extend to xacts
335-
* that do catalog accesses. this is unfortunate, but not critical.
336326
*/
337327
bool
338328
HeapTupleSatisfiesNow(HeapTupleHeader tuple, Snapshot snapshot, Buffer buffer)

0 commit comments

Comments
 (0)