postgres.git / summary / log / commit / refs

commit    0908c5ecf0833b020b0d95183804ebc22bb6ea6c
Author:   Thomas Munro <tmunro@postgresql.org>
Date:     Thu Jun 27 23:11:26 2019 +0000
First released in: 12.0, 9.4.24, 9.5.19, 9.6.15, 10.10, 11.5

    Fix misleading comment in nodeIndexonlyscan.c.
    
    The stated reason for acquiring predicate locks on heap pages hasn't
    existed since commit c01262a8, so fix the comment.  Perhaps in a later
    release we'll also be able to change the code to use tuple locks.
    
    Back-patch all the way.
    
    Reviewed-by: Ashwin Agrawal
    Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com


 src/backend/executor/nodeIndexonlyscan.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/backend/executor/nodeIndexonlyscan.c b/src/backend/executor/nodeIndexonlyscan.c
index 4f6f91c8dba..24a718d5366 100644
--- a/src/backend/executor/nodeIndexonlyscan.c
+++ b/src/backend/executor/nodeIndexonlyscan.c
@@ -179,11 +179,8 @@ IndexOnlyNext(IndexOnlyScanState *node)
 					 errmsg("lossy distance functions are not supported in index-only scans")));
 
 		/*
-		 * Predicate locks for index-only scans must be acquired at the page
-		 * level when the heap is not accessed, since tuple-level predicate
-		 * locks need the tuple's xmin value.  If we had to visit the tuple
-		 * anyway, then we already have the tuple-level lock and can skip the
-		 * page lock.
+		 * If we didn't access the heap, then we'll need to take a predicate
+		 * lock explicitly, as if we had.  For now we do that at page level.
 		 */
 		if (tuple == NULL)
 			PredicateLockPage(scandesc->heapRelation,


[parent: 30e1b395c9cf]