Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock

On Sat, Oct 1, 2022 at 12:35 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> This issue does occasionally happen in CI, as e.g. noted in this thread:
> https://www.postgresql.org/message-id/20220930185345.GD6256%40telsasoft.com
>
> On 2022-08-18 15:17:47 +0530, Amit Kapila wrote:
> > I agree with you that getting rid of the clean-up lock on the new
> > bucket is a more invasive patch and should be done separately if
> > required. Yesterday, I have done a brief analysis and I think that is
> > possible but it doesn't seem to be a good idea to backpatch it.
>
> My problem with this approach is that the whole cleanup lock is hugely
> misleading as-is. As I noted in
> https://www.postgresql.org/message-id/20220817193032.z35vdjhpzkgldrd3%40awork3.anarazel.de
> we take the cleanup lock *after* re-initializing the page. Thereby
> completely breaking the properties that a cleanup lock normally tries to
> guarantee.
>
> Even if that were to achieve something useful (doubtful in this case),
> it'd need a huge comment explaining what's going on.
>

Attached are two patches. The first patch is what Robert has proposed
with some changes in comments to emphasize the fact that cleanup lock
on the new bucket is just to be consistent with the old bucket page
locking as we are initializing it just before checking for cleanup
lock. In the second patch, I removed the acquisition of cleanup lock
on the new bucket page and changed the comments/README accordingly.

I think we can backpatch the first patch and the second patch can be
just a HEAD-only patch. Does that sound reasonable to you?

--
With Regards,
Amit Kapila.