Hi, On 2024-04-10 16:05:21 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I think it could exascerbate the issue. Parag reported ~7k connections on a > > 128 core machine. The buffer replacement logic in < 16 tries to lock the old > > and new lock partitions at once. That can lead to quite bad "chains" of > > dependent lwlocks, occasionally putting all the pressure on a single lwlock. > > With 7k waiters on a single spinlock, higher frequency of wakeups will make > > it > > much more likely that the process holding the spinlock will be put to sleep. > > This is greatly exacerbated by the issue fixed in a4adc31f690, once the > > waitqueue is long, the spinlock will be held for an extended amount of time. > > Yeah. So what's the conclusion? Leave it alone? Commit to > HEAD only?
I think we should certainly fix it. I don't really have an opinion about backpatching, it's just on the line between the two for me. Hm. The next set of releases is still a bit away, and this is one of the period where HEAD is hopefully going to be more tested than usual, so I'd perhaps very softly lean towards backpatching. There'd have to be some very odd compiler behaviour to make it slower than before anyway. Greetings, Andres Freund
