Re: verify predefined LWLocks have entries in wait_event_names.txt
| От | Robert Haas |
|---|---|
| Тема | Re: verify predefined LWLocks have entries in wait_event_names.txt |
| Дата | |
| Msg-id | CA+TgmoZGDO_hx8QvFkgj29JjyWm1+YJRELySwuLqiTJymAGVSw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: verify predefined LWLocks have entries in wait_event_names.txt (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: verify predefined LWLocks have entries in wait_event_names.txt
|
| Список | pgsql-hackers |
On Tue, Jan 2, 2024 at 4:45 PM Nathan Bossart <nathandbossart@gmail.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
В списке pgsql-hackers по дате отправления: