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
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 |