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

From Amit Kapila
Subject Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Date
Msg-id CAA4eK1LuN7vMFew5QDBBbFqLjCRnHXUq0QNx5CxCh-nJbhwTjg@mail.gmail.com
Whole thread Raw
In response to Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Oct 18, 2022 at 8:25 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Oct 17, 2022 at 4:30 PM Andres Freund <andres@anarazel.de> wrote:
> > On 2022-10-17 13:34:02 -0400, Robert Haas wrote:
>
> Maybe just nuking the IsBufferCleanupOK call is best, I don't know. I
> honestly doubt that it matters very much what we pick here.
>

Agreed, I think the important point to decide is what to do for
back-branches. We have the next minor release in a few days' time and
this is the last release for v10. I see the following options based on
the discussion here.

a. Use the code change in 0001 from email [1] and a comment change
proposed by Robert in email [2] to fix the bug reported. This should
be backpatched till v10. Then separately, we can consider committing
something like 0002 from email [1] as a HEAD-only patch.
b. Use the code change in 0001 from email [1] to fix the bug reported.
This should be backpatched till v10. Then separately, we can consider
committing something like 0002 from email [1] as a HEAD-only patch.
c. Combine 0001 and 0002 from the email [1] and push them in all
branches till v10.

I prefer going with (a).

[1] - https://www.postgresql.org/message-id/CAA4eK1LekwAZU5yf2h%2BW1Ko_c85TZHuNLg6jVPD6KDXrYYFo1g%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CA%2BTgmoYruVb7Nh5TUt47sTyYui2zE8Ke9T3DcHeB1wSkb%3DuSCw%40mail.gmail.com

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: heavily contended lwlocks with long wait queues scale badly
Next
From: Dilip Kumar
Date:
Subject: Re: Code checks for App Devs, using new options for transaction behavior