verify predefined LWLocks have entries in wait_event_names.txt

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: verify predefined LWLocks have entries in wait_event_names.txt
Date: 2024-01-02 17:31:20
Message-ID: 20240102173120.GA1061678@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(new thread)

On Tue, Jan 02, 2024 at 10:34:11AM -0500, Robert Haas wrote:
> On Wed, Dec 27, 2023 at 10:36 AM Nathan Bossart
> <nathandbossart(at)gmail(dot)com> wrote:
>> Thanks! I also noticed that WALSummarizerLock probably needs a mention in
>> wait_event_names.txt.
>
> Fixed.

I think we're supposed to omit the "Lock" suffix in wait_event_names.txt.

> It seems like it would be good if there were an automated cross-check
> between lwlocknames.txt and wait_event_names.txt.

+1. Here's a hastily-thrown-together patch for that. I basically copied
003_check_guc.pl and adjusted it for this purpose. This test only checks
that everything in lwlocknames.txt has a matching entry in
wait_event_names.txt. It doesn't check that everything in the predefined
LWLock section of wait_event_names.txt has an entry in lwlocknames.txt.
AFAICT that would be a little more difficult because you can't distinguish
between the two in pg_wait_events.

Even with this test, I worry that we could easily forget to add entries in
wait_event_names.txt for the non-predefined locks, but I don't presently
have a proposal for how to prevent that.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v1-0001-verify-wait-events-for-all-lwlocks.patch text/x-diff 3.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kumar, Sachin 2024-01-02 17:33:00 Re: pg_upgrade failing for 200+ million Large Objects
Previous Message Tom Lane 2024-01-02 16:56:12 Re: The presence of a NULL "defaclacl" value in pg_default_acl prevents the dropping of a role.