Re: An out-of-date comment in nodeIndexonlyscan.c
От | Thomas Munro |
---|---|
Тема | Re: An out-of-date comment in nodeIndexonlyscan.c |
Дата | |
Msg-id | CA+hUKGJi8SNv02ymFnY8k8g=podH8mOJb=yK4KPw7hyQ0nZkaw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: An out-of-date comment in nodeIndexonlyscan.c (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: An out-of-date comment in nodeIndexonlyscan.c
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: