Re: An out-of-date comment in nodeIndexonlyscan.c

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: An out-of-date comment in nodeIndexonlyscan.c
Date: 2018-05-16 17:48:26
Message-ID: 340dc088-8332-e2f8-3bca-14d3c3fb2b41@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-05-16 18:01:48 Re: Problem while updating a foreign table pointing to a partitioned table on foreign server
Previous Message Heikki Linnakangas 2018-05-16 17:17:38 Re: Memory unit GUC range checks