Обсуждение: Fix lwlock.c and wait_event_names.txt discrepancy
Hi hackers, While working on [1], I noticed a discrepancy between lwlock.c and wait_event_names.txt for 2 wait events. Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU in the C file but MultiXactOffsetSLRU and MultiXactMemberSLRU in the text file. That breaks joins between pg_stat_activity and pg_wait_events on the wait event name. PFA a patch to fix those (I'm not able to find other discrepancy with the "automated" work I'm doing in [1], so I'm confident there is no others). Oversight in commit 53c2a97a9266. [1]: https://www.postgresql.org/message-id/aHZiHZ8sSQdHpyM6%40bdt-Laptop-13th-Gen-Intel-Core Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
On Wed, Jul 16, 2025 at 09:30:31AM +0000, Bertrand Drouvot wrote: > While working on [1], I noticed a discrepancy between lwlock.c and > wait_event_names.txt for 2 wait events. Oops. > Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU in > the C file but MultiXactOffsetSLRU and MultiXactMemberSLRU in the text file. > > That breaks joins between pg_stat_activity and pg_wait_events on the wait > event name. PFA a patch to fix those (I'm not able to find other discrepancy > with the "automated" work I'm doing in [1], so I'm confident there is no others). > > Oversight in commit 53c2a97a9266. This is in the same line as 08b9b9e043bb, down to v17. For 08b9b9e043bb, we were lucky enough to not be in GA, would people mind to sneak this lwlock tranche name change in v17? In v16 and older versions, we have been using MultiXactOffsetSLRU (documented), not MultixactOffsetSLRU. So there is some history here. -- Michael
Вложения
On 2025-Jul-16, Michael Paquier wrote: > On Wed, Jul 16, 2025 at 09:30:31AM +0000, Bertrand Drouvot wrote: > > Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU in > > the C file but MultiXactOffsetSLRU and MultiXactMemberSLRU in the text file. > > > > That breaks joins between pg_stat_activity and pg_wait_events on the wait > > event name. PFA a patch to fix those (I'm not able to find other discrepancy > > with the "automated" work I'm doing in [1], so I'm confident there is no others). > > This is in the same line as 08b9b9e043bb, down to v17. For > 08b9b9e043bb, we were lucky enough to not be in GA, would people mind > to sneak this lwlock tranche name change in v17? I don't. These names are unlikely to be anywhere other than in the output of queries for any length of time, so if we change them now, nothing will break permanently. I grant that there might be small temporary breakage if somebody is storing wait event samples or similar, but I doubt it'll be a problem to change it. Long-term lack of joinability between pg_stat_activity and pg_wait_events in the 17 branch would likely be a bigger problem. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "The problem with the facetime model is not just that it's demoralizing, but that the people pretending to work interrupt the ones actually working." -- Paul Graham, http://www.paulgraham.com/opensource.html
Hi, On Wed, Jul 16, 2025 at 01:33:07PM +0200, Álvaro Herrera wrote: > On 2025-Jul-16, Michael Paquier wrote: > > > On Wed, Jul 16, 2025 at 09:30:31AM +0000, Bertrand Drouvot wrote: > > > > Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU in > > > the C file but MultiXactOffsetSLRU and MultiXactMemberSLRU in the text file. > > > > > > That breaks joins between pg_stat_activity and pg_wait_events on the wait > > > event name. PFA a patch to fix those (I'm not able to find other discrepancy > > > with the "automated" work I'm doing in [1], so I'm confident there is no others). > > > > This is in the same line as 08b9b9e043bb, down to v17. For > > 08b9b9e043bb, we were lucky enough to not be in GA, would people mind > > to sneak this lwlock tranche name change in v17? > > I don't. These names are unlikely to be anywhere other than in the > output of queries for any length of time, so if we change them now, > nothing will break permanently. I grant that there might be small > temporary breakage if somebody is storing wait event samples or similar, > but I doubt it'll be a problem to change it. Long-term lack of > joinability between pg_stat_activity and pg_wait_events in the 17 branch > would likely be a bigger problem. +1 As a way to prevent this to occur we might want to add extra input file(s) parameter to generate-wait_event_types.pl (as proposed in [1]). [1]: https://www.postgresql.org/message-id/flat/aDQdDhcwMHjZRhSV%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
On Wed, Jul 16, 2025 at 11:41:09AM +0000, Bertrand Drouvot wrote: > On Wed, Jul 16, 2025 at 01:33:07PM +0200, Álvaro Herrera wrote: >> I don't. These names are unlikely to be anywhere other than in the >> output of queries for any length of time, so if we change them now, >> nothing will break permanently. I grant that there might be small >> temporary breakage if somebody is storing wait event samples or similar, >> but I doubt it'll be a problem to change it. Long-term lack of >> joinability between pg_stat_activity and pg_wait_events in the 17 branch >> would likely be a bigger problem. > > +1 Thanks. Perhaps I am worrying to much about the profiles taken on REL_17_STABLE, but after sleeping on it the long-term picture is better if we are consistent on all the branches, so done down to v17. Thanks for the report. > As a way to prevent this to occur we might want to add extra input file(s) > parameter to generate-wait_event_types.pl (as proposed in [1]). > > [1]: https://www.postgresql.org/message-id/flat/aDQdDhcwMHjZRhSV%40ip-10-97-1-34.eu-west-3.compute.internal That's the second issue so far, so we had better do so. -- Michael
Вложения
Hi, On Thu, Jul 17, 2025 at 09:50:12AM +0900, Michael Paquier wrote: > On Wed, Jul 16, 2025 at 11:41:09AM +0000, Bertrand Drouvot wrote: > > > As a way to prevent this to occur we might want to add extra input file(s) > > parameter to generate-wait_event_types.pl (as proposed in [1]). > > > > [1]: https://www.postgresql.org/message-id/flat/aDQdDhcwMHjZRhSV%40ip-10-97-1-34.eu-west-3.compute.internal > > That's the second issue so far, so we had better do so. Yeah, I'll look at it. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Hi, On Thu, Jul 17, 2025 at 02:25:46PM +0000, Bertrand Drouvot wrote: > Hi, > > On Thu, Jul 17, 2025 at 09:50:12AM +0900, Michael Paquier wrote: > > On Wed, Jul 16, 2025 at 11:41:09AM +0000, Bertrand Drouvot wrote: > > > > > As a way to prevent this to occur we might want to add extra input file(s) > > > parameter to generate-wait_event_types.pl (as proposed in [1]). > > > > > > [1]: https://www.postgresql.org/message-id/flat/aDQdDhcwMHjZRhSV%40ip-10-97-1-34.eu-west-3.compute.internal > > > > That's the second issue so far, so we had better do so. > > Yeah, I'll look at it. Done in [1]. [1]: https://www.postgresql.org/message-id/aHpOgwuFQfcFMZ/B%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com