Hi,
On 2023-11-16 15:29:38 -0500, Robert Haas 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.
Yea, that'd make it easy :)
> 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.
I think the main reason it's not all that bad, even when hitting this path, is
that one stall every 8GB just isn't that much and that the stalls aren't that
long - the leaf page fsm updates don't use the strategy, so they're still
somewhat likely to be in s_b, and there's "just" ~2MB of FMS to read. I tried
to reproduce it here, and it was a few ms, even though I dropped filesystem
caches in a loop.
Greetings,
Andres Freund