Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock - Mailing list pgsql-hackers

From Robert Haas
Subject Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Date
Msg-id CA+Tgmoa_e6sisNKaWOpjWTH4TTozL7n2eyWFLd6f9PvzxqkaAg@mail.gmail.com
Whole thread Raw
In response to Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock  (Andres Freund <andres@anarazel.de>)
Responses Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
List pgsql-hackers
On Wed, Aug 17, 2022 at 2:45 PM Andres Freund <andres@anarazel.de> wrote:
> On 2022-08-17 08:25:06 -0400, Robert Haas wrote:
> > Regarding the question of whether we need a cleanup lock on the new
> > bucket I am not really seeing the advantage of going down that path.
> > Simply fixing this code to take a cleanup lock instead of hoping that
> > it always gets one by accident is low risk and should fix the observed
> > problem. Getting rid of the cleanup lock will be more invasive and I'd
> > like to see some evidence that it's a necessary step before we take
> > the risk of breaking things.
>
> Given that the cleanup locks in question are "taken" *after* re-initializing
> the page, I'm doubtful that's a sane path forward. It seems quite likely to
> mislead somebody to rely on it working as a cleanup lock in the future.

There's not a horde of people lining up to work on the hash index
code, but if you feel like writing and testing the more invasive fix,
I'm not really going to fight you over it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: static libpq (and other libraries) overwritten on aix
Next
From: Robert Haas
Date:
Subject: Re: static libpq (and other libraries) overwritten on aix