Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Date: 2023-11-17 00:43:43
Message-ID: CAAKRu_Y+rP+TcjjvomzKo8N+EeHc0Bonb6rwLv4kSkaqiHL7yA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 16, 2023 at 3:29 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Nov 15, 2023 at 6:17 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-11-17 00:46:10 Re: Faster "SET search_path"
Previous Message shihao zhong 2023-11-16 23:25:33 Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document