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

From Robert Haas
Subject Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Date
Msg-id CA+TgmoaSd03ptCA+Cz_F8bxuRrCC3x77ozmmLV+MhwUccSfaaA@mail.gmail.com
Whole thread Raw
In response to Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM  (Andres Freund <andres@anarazel.de>)
Responses Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
List 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 by date:

Previous
From: Jubilee Young
Date:
Subject: Hide exposed impl detail of wchar.c
Next
From: Andres Freund
Date:
Subject: Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM