Re: Autogenerate some wait events code and documentation

On Sun, Jul 16, 2023 at 12:21:20PM -0700, Andres Freund wrote:
> I think the search issue is valid, so I do think going the other way is
> preferrable. I.e. use just the enum value in the .txt and generate the camel
> case name from that. That allows you to search the define used in code and
> find a hit in the file.
>
> I personally would still leave off the WAIT_EVENT prefix in the .txt, I think
> most of us can remember to chop that off.

So you mean to switch a line that now looks like that:
WAIT_EVENT_FOO_BAR FooBar "Waiting on Foo Bar."
To that:
FOO_BAR "Waiting on Foo Bar."
Or even that:
WAIT_EVENT_FOO_BAR "Waiting on Foo Bar."

Sure, it is an improvement for any wait events that use WAIT_EVENT_
when searching them, but this adds more magic into the LWLock and Lock
areas if the same conversion is applied there. Or am I right to
assume that you'd mean to *not* do any of that for these two classes?
These can be treated as exceptions in the script when generating the
wait event names from the enum elements, of course.

> I don't think we need to be particularly consistent with wait events across
> major versions. They're necessarily tied to how the code works, and we've
> yanked that around plenty.

IMO, it depends on the code path involved. For example, I know of
some code that relies on SyncRep to track backends waiting on a sync
reply, and that's one sensible to keep compatible. I'd be sad if
something like that breaks suddenly after a major release.
--
Michael