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

Поиск
Список
Период
Сортировка
От Melanie Plageman
Тема Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Дата
Msg-id CAAKRu_Y+rP+TcjjvomzKo8N+EeHc0Bonb6rwLv4kSkaqiHL7yA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: shihao zhong
Дата:
Сообщение: Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Faster "SET search_path"