Re: verify predefined LWLocks have entries in wait_event_names.txt

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

On Fri, Jan 05, 2024 at 10:42:03AM -0600, Nathan Bossart wrote:
> On Fri, Jan 05, 2024 at 07:39:39AM +0000, Bertrand Drouvot wrote:
>> + die "lists of predefined LWLocks in lwlocknames.txt and wait_event_names.txt do not match"
>> + unless $wait_event_lwlocks[$i] eq $lockname;
>>
>> What about printing $wait_event_lwlocks[$i] and $lockname in the error message?
>> Something like?
>>
>> "
>> die "lists of predefined LWLocks in lwlocknames.txt and wait_event_names.txt do not match (comparing $lockname and $wait_event_lwlocks[$i])"
>> unless $wait_event_lwlocks[$i] eq $lockname;
>> "
>>
>> I think that would give more clues for debugging purpose.
>
> Sure, I'll add something like that. I think this particular scenario is
> less likely, but that's not a reason to make the error message hard to
> decipher.

Here is a new version of the patch with this change.

I also tried to make the verification logic less fragile. Instead of
depending on the exact location of empty lines in wait_event_names.txt, v3
adds a marker comment below the list that clearly indicates it should not
be changed. This simplifies the verification code a bit, too.

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

Attachment Content-Type Size
v3-0001-verify-lists-of-predefined-LWLocks-in-lwlocknames.patch text/x-diff 6.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Eric Hanson 2024-01-05 17:48:03 Re: SET ROLE x NO RESET
Previous Message Robert Haas 2024-01-05 17:41:56 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs