Re: An out-of-date comment in nodeIndexonlyscan.c - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: An out-of-date comment in nodeIndexonlyscan.c
Date
Msg-id 340dc088-8332-e2f8-3bca-14d3c3fb2b41@iki.fi
Whole thread Raw
In response to An out-of-date comment in nodeIndexonlyscan.c  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: An out-of-date comment in nodeIndexonlyscan.c
List pgsql-hackers
On 14/05/18 02:15, Thomas Munro wrote:
> Hello,
> 
> Since commit cdf91edb (2012), nodeIndexonlyscan.c says:
> 
>                  /*
>                   * 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 (tuple == NULL)
>                          PredicateLockPage(scandesc->heapRelation,
> 
> ItemPointerGetBlockNumber(tid),
>                                                            estate->es_snapshot);
> 
> The first sentence of that comment is no longer true as of commit
> c01262a8 (2013).  As for whether it's necessary to predicate-lock the
> whole eheap page (rather than the heap tuple) anyway because of HOT
> update chains, I don't know, so I'm not sure what wording to propose
> instead.

Hmm. If there are any updated tuples, HOT or not, the visibility map bit 
will not be set, and we won't reach this code. So I think we could 
acquire the tuple lock here.

- Heikki


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Memory unit GUC range checks
Next
From: Robert Haas
Date:
Subject: Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server