On Thu, Nov 16, 2017 at 12:44 PM, Robert Haas <robertmh...@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
