From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(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: | Re: verify predefined LWLocks have entries in wait_event_names.txt |
Date: | 2024-01-03 03:49:03 |
Message-ID: | CA+TgmoZGDO_hx8QvFkgj29JjyWm1+YJRELySwuLqiTJymAGVSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 2, 2024 at 4:45 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> That seems to date back to commit 14a9101. I can agree that the suffix is
> somewhat redundant since these are already marked as type "LWLock", but
> I'll admit I've been surprised by this before, too. IMHO it makes this
> proposed test more important because you can't just grep for a different
> lock to find all the places you need to update.
I agree. I am pretty sure that the reason this happened in the first
place is that I grepped for the name of some other LWLock and adjusted
things for the new lock at every place where that found a hit.
> > - Check in both directions instead of just one?
> >
> > - Verify ordering?
>
> To do those things, I'd probably move the test to one of the scripts that
> generates the documentation or header file (pg_wait_events doesn't tell us
> whether a lock is predefined or what order it's listed in). That'd cause
> failures at build time instead of during testing, which might be kind of
> nice, too.
Yeah, I think that would be better.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-01-03 05:04:17 | LLVM 18 |
Previous Message | Amit Kapila | 2024-01-03 03:23:44 | Re: Track in pg_replication_slots the reason why slots conflict? |