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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Дата
Msg-id CA+TgmoaSd03ptCA+Cz_F8bxuRrCC3x77ozmmLV+MhwUccSfaaA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM  (Andres Freund <andres@anarazel.de>)
Ответы Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Список pgsql-hackers
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.

Until just now, I hadn't quite absorbed the fact that this only
affected the indexes == 0 case; that case is probably extremely rare
in real life. It's possible that accounts for why this hasn't caused
more trouble. But there could also be reasons why, even if you do have
that use case, this tends not to be too serious.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jubilee Young
Дата:
Сообщение: Hide exposed impl detail of wchar.c
Следующее
От: Andres Freund
Дата:
Сообщение: Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM