On Fri, Feb 8, 2019 at 4:58 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, May 17, 2018 at 3:49 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > On 14/05/18 02:15, Thomas Munro wrote:
> > > 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.
>
> Right. CC Kevin. I think we should at least fix the comment. As for
> changing the lock level, PredicateLockTuple() wants a heap tuple that
> we don't have, so we'd probably need to add a PredicateLockTid()
> function.
Here's a patch I'd like to commit to fix the comment. We could look
at improving the actual code after
https://commitfest.postgresql.org/23/2169/ is done.
I wonder if it might be possible to avoid page locks on both the heap
*and* index in some limited cases, as I mentioned over here (just an
idea, could be way off base):
https://www.postgresql.org/message-id/CA%2BhUKGJGDVfhHmoUGzi-_J%2BN8FmRjmWTY0MCd1ZV5Fj9qdyb1w%40mail.gmail.com
--
Thomas Munro
https://enterprisedb.com
