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
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 |