Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted |
Дата | |
Msg-id | CAH2-Wzn0OXhMesmxUvk9_F75KaPH52FU=wj6xmWaGJTE3gvMOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted
|
Список | pgsql-hackers |
On Thu, Nov 16, 2017 at 12:44 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I would like to get rid of that LockPage() call, for sure, because > it's problematic in terms of allowing writes in parallel mode. > However, I think the reason here is the same as why the hash AM used > to use them. If you use a buffer lock, you really can't -- or > shoudn't, at least -- hold it across a whole series of operations, > because anyone waiting for that lock is waiting *uninterruptibly*. I'm well aware of that. > The hash AM wanted to iterate through all of the pages in a bucket > chain and do something to each one while preventing concurrent scans; > the need here is similar. Aside from the uninterruptible-wait > problem, such coding patterns are extremely prone to deadlock. If > there's any chance that a process waiting for the buffer lock you hold > might be holding a buffer lock you try to acquire, you have got a > problem. But there is only ever one page locked, the meta-page. And, it's always an ExclusiveLock. I don't see much use for deadlock avoidance. In any case, it's unusual to have a patch that uses LockPage() without explaining the choice. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: