Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Date
Msg-id CAAKRu_Y+rP+TcjjvomzKo8N+EeHc0Bonb6rwLv4kSkaqiHL7yA@mail.gmail.com
Whole thread Raw
In response to Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Nov 16, 2023 at 3:29 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Nov 15, 2023 at 6:17 PM Andres Freund <andres@anarazel.de> wrote:
> > Thoughts on whether to backpatch? It'd probably be at least a bit painful,
> > there have been a lot of changes in the surrounding code in the last 5 years.
>
> I guess the main point that I'd make here is that we shouldn't
> back-patch because it's wrong, but because of whatever consequences it
> being wrong has. If somebody demonstrates that a deadlock occurs, or
> that a painfully long stall can be constructed on a somewhat realistic
> test case, then I think we should back-patch. If it's just something
> that we look at and by visual inspection say "wow, that looks awful,"
> that is not a sufficient reason to back-patch in my view. Such a
> back-patch would still have known risk, but no known reward.

This reasoning makes sense, and I hadn't really thought of it that way.
I was going to offer to take a stab at producing some back patch sets,
but, given this rationale and Andres' downthread agreement and
analysis, it sounds like there is no reason to do so. Thanks for
thinking about my bug report!

- Melanie



pgsql-hackers by date:

Previous
From: shihao zhong
Date:
Subject: Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document
Next
From: Jeff Davis
Date:
Subject: Re: Faster "SET search_path"