Fix lwlock.c and wait_event_names.txt discrepancy

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]/messages/by-id/aDQdDhcwMHjZRhSV@ip-10-97-1-34.eu-west-3.compute.internal).

[1]: /messages/by-id/aDQdDhcwMHjZRhSV@ip-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]: /messages/by-id/aDQdDhcwMHjZRhSV@ip-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]: /messages/by-id/aDQdDhcwMHjZRhSV@ip-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]: /messages/by-id/aDQdDhcwMHjZRhSV@ip-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]/messages/by-id/aHpOgwuFQfcFMZ/B@ip-10-97-1-34.eu-west-3.compute.internal.

[1]: /messages/by-id/aHpOgwuFQfcFMZ/B@ip-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