Re: heavily contended lwlocks with long wait queues scale badly
От | Jonathan S. Katz |
---|---|
Тема | Re: heavily contended lwlocks with long wait queues scale badly |
Дата | |
Msg-id | 4192c42a-24fe-456b-b01a-cc5a44568cc0@postgresql.org обсуждение исходный текст |
Ответ на | Re: heavily contended lwlocks with long wait queues scale badly (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: heavily contended lwlocks with long wait queues scale badly
|
Список | pgsql-hackers |
On 1/10/24 10:45 PM, Michael Paquier wrote: > On Wed, Jan 10, 2024 at 09:17:47PM -0600, Nathan Bossart wrote: >> Now that commit a4adc31 has had some time to bake and concerns about >> unintended consequences may have abated, I wanted to revive this >> back-patching discussion. I see a few possibly-related reports [0] [1] >> [2], and I'm now seeing this in the field, too. While it is debatable >> whether this is a bug, it's a quite nasty issue for users, and it's both >> difficult to detect and difficult to work around. > > +1, I've seen this becoming a PITA for a few things. Knowing that the > size of PGPROC does not change at all, I would be in favor for a > backpatch, especially since it's been in the tree for more than 1 > year, and even more knowing that we have 16 released with this stuff > in. I have similar data sources to Nathan/Michael and I'm trying to avoid piling on, but one case that's interesting occurred after a major version upgrade from PG10 to PG14 on a database supporting a very active/highly concurrent workload. On inspection, it seems like backpatching would help this particularly case. With 10/11 EOL, I do wonder if we'll see more of these reports on upgrade to < PG16. (I was in favor of backpatching prior; opinion is unchanged). Thanks, Jonathan
Вложения
В списке pgsql-hackers по дате отправления: