Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
Date
Msg-id CAH2-WznhkRLYMDjes+n+qpggq7W6hBGsMuw+4yrs15ErJo-14Q@mail.gmail.com
Whole thread Raw
In response to Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock  (Andrey Borodin <x4mmm@yandex-team.ru>)
Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock  (Alexander Korotkov <aekorotkov@gmail.com>)
List pgsql-hackers
On Thu, Dec 6, 2018 at 12:51 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> So, algorithm introduced by 218f51584d5 is broken.  It tries to
> guarantee that there are no inserters in the subtree by placing
> cleanup lock to subtree root, assuming that inserter holds pins on the
> path from root to leaf.  But due to concurrent splits of internal
> pages the pins held can be not relevant to actual path.  I don't see
> the way to fix this easily.  So, I think we should revert it from back
> branches and try to reimplement that in master.
>
> However, I'd like to note that 218f51584d5 introduces two changes:
> 1) Cleanup locking only if there pages to delete
> 2) Cleanup locking only subtree root
> The 2nd one is broken.  But the 1st one seems still good for me and
> useful, because in vast majority of cases vacuum doesn't delete any
> index pages.  So, I propose to revert 218f51584d5, but leave there
> logic, which locks root for cleanup only once there are pages to
> delete.  Any thoughts?

Can you post a patch that just removes the 2nd part, leaving the
still-correct first part?

Your proposal sounds reasonable, but I'd like to see what you have in
mind in detail before commenting.

Thanks
-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Compressed TOAST Slicing
Next
From: Alvaro Herrera
Date:
Subject: don't create storage when unnecessary