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

Commit ebcc7bf

Browse files
committed
Rephrase references to "time qualification".
Now that the relevant code has, for other reasons, moved out of tqual.[ch], it seems time to refer to visiblity rather than time qualification. Author: Andres Freund Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
1 parent c91560d commit ebcc7bf

File tree

4 files changed

+7
-7
lines changed

4 files changed

+7
-7
lines changed

doc/src/sgml/indexam.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -720,7 +720,7 @@ amparallelrescan (IndexScanDesc scan);
720720
the TIDs of all the tuples it has been told about that match the
721721
<firstterm>scan keys</firstterm>. The access method is <emphasis>not</emphasis> involved in
722722
actually fetching those tuples from the index's parent table, nor in
723-
determining whether they pass the scan's time qualification test or other
723+
determining whether they pass the scan's visibility test or other
724724
conditions.
725725
</para>
726726

src/backend/access/heap/heapam.c

+3-3
Original file line numberDiff line numberDiff line change
@@ -1700,7 +1700,7 @@ heap_fetch(Relation relation,
17001700
tuple->t_tableOid = RelationGetRelid(relation);
17011701

17021702
/*
1703-
* check time qualification of tuple, then release lock
1703+
* check tuple visibility, then release lock
17041704
*/
17051705
valid = HeapTupleSatisfiesVisibility(tuple, snapshot, buffer);
17061706

@@ -2020,8 +2020,8 @@ heap_get_latest_tid(Relation relation,
20202020
}
20212021

20222022
/*
2023-
* Check time qualification of tuple; if visible, set it as the new
2024-
* result candidate.
2023+
* Check tuple visibility; if visible, set it as the new result
2024+
* candidate.
20252025
*/
20262026
valid = HeapTupleSatisfiesVisibility(&tp, snapshot, buffer);
20272027
CheckForSerializableConflictOut(valid, relation, &tp, buffer, snapshot);

src/backend/access/heap/heapam_visibility.c

+2-2
Original file line numberDiff line numberDiff line change
@@ -1453,8 +1453,8 @@ HeapTupleIsSurelyDead(HeapTuple htup, TransactionId OldestXmin)
14531453
* It's easy to check just infomask bits if the locker is not a multi; but
14541454
* otherwise we need to verify that the updating transaction has not aborted.
14551455
*
1456-
* This function is here because it follows the same time qualification rules
1457-
* laid out at the top of this file.
1456+
* This function is here because it follows the same visibility rules laid out
1457+
* at the top of this file.
14581458
*/
14591459
bool
14601460
HeapTupleHeaderIsOnlyLocked(HeapTupleHeader tuple)

src/backend/utils/cache/inval.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
*
66
* This is subtle stuff, so pay attention:
77
*
8-
* When a tuple is updated or deleted, our standard time qualification rules
8+
* When a tuple is updated or deleted, our standard visibility rules
99
* consider that it is *still valid* so long as we are in the same command,
1010
* ie, until the next CommandCounterIncrement() or transaction commit.
1111
* (See acces/heap/heapam_visibility.c, and note that system catalogs are

0 commit comments

Comments
 (0)