mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-31 00:03:57 -04:00 
			
		
		
		
	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
This commit is contained in:
		
							parent
							
								
									c91560defc
								
							
						
					
					
						commit
						ebcc7bf949
					
				| @ -720,7 +720,7 @@ amparallelrescan (IndexScanDesc scan); | ||||
|    the TIDs of all the tuples it has been told about that match the | ||||
|    <firstterm>scan keys</firstterm>.  The access method is <emphasis>not</emphasis> involved in | ||||
|    actually fetching those tuples from the index's parent table, nor in | ||||
|    determining whether they pass the scan's time qualification test or other | ||||
|    determining whether they pass the scan's visibility test or other | ||||
|    conditions. | ||||
|   </para> | ||||
| 
 | ||||
|  | ||||
| @ -1700,7 +1700,7 @@ heap_fetch(Relation relation, | ||||
| 	tuple->t_tableOid = RelationGetRelid(relation); | ||||
| 
 | ||||
| 	/*
 | ||||
| 	 * check time qualification of tuple, then release lock | ||||
| 	 * check tuple visibility, then release lock | ||||
| 	 */ | ||||
| 	valid = HeapTupleSatisfiesVisibility(tuple, snapshot, buffer); | ||||
| 
 | ||||
| @ -2020,8 +2020,8 @@ heap_get_latest_tid(Relation relation, | ||||
| 		} | ||||
| 
 | ||||
| 		/*
 | ||||
| 		 * Check time qualification of tuple; if visible, set it as the new | ||||
| 		 * result candidate. | ||||
| 		 * Check tuple visibility; if visible, set it as the new result | ||||
| 		 * candidate. | ||||
| 		 */ | ||||
| 		valid = HeapTupleSatisfiesVisibility(&tp, snapshot, buffer); | ||||
| 		CheckForSerializableConflictOut(valid, relation, &tp, buffer, snapshot); | ||||
|  | ||||
| @ -1453,8 +1453,8 @@ HeapTupleIsSurelyDead(HeapTuple htup, TransactionId OldestXmin) | ||||
|  * It's easy to check just infomask bits if the locker is not a multi; but | ||||
|  * otherwise we need to verify that the updating transaction has not aborted. | ||||
|  * | ||||
|  * This function is here because it follows the same time qualification rules | ||||
|  * laid out at the top of this file. | ||||
|  * This function is here because it follows the same visibility rules laid out | ||||
|  * at the top of this file. | ||||
|  */ | ||||
| bool | ||||
| HeapTupleHeaderIsOnlyLocked(HeapTupleHeader tuple) | ||||
|  | ||||
							
								
								
									
										2
									
								
								src/backend/utils/cache/inval.c
									
									
									
									
										vendored
									
									
								
							
							
						
						
									
										2
									
								
								src/backend/utils/cache/inval.c
									
									
									
									
										vendored
									
									
								
							| @ -5,7 +5,7 @@ | ||||
|  * | ||||
|  *	This is subtle stuff, so pay attention: | ||||
|  * | ||||
|  *	When a tuple is updated or deleted, our standard time qualification rules | ||||
|  *	When a tuple is updated or deleted, our standard visibility rules | ||||
|  *	consider that it is *still valid* so long as we are in the same command, | ||||
|  *	ie, until the next CommandCounterIncrement() or transaction commit. | ||||
|  *	(See acces/heap/heapam_visibility.c, and note that system catalogs are | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user