On Wed, Jul 05, 2023 at 02:59:39PM -0700, Andres Freund wrote:
> Rebasing a patch over this I was a bit confused because I got a bunch of
> ""unable to parse wait_event_names.txt" errors. Took me a while to figure out
> that that was just because I didn't include a trailing . in the description.
> Perhaps that could be turned into a more meaningful error?
>
> die "unable to parse wait_event_names.txt"
> unless $line =~ /^(\w+)\t+(\w+)\t+("\w+")\t+("\w.*\.")$/;
Agreed that we could at least add the $line in the error message
generated, at least, to help with debugging.
> I also do wonder if we should invest in generating the lwlock names as
> well. Except for a few abbreviations, the second column is always the
> camel-cased version of what follows WAIT_EVENT_. Feels pretty tedious to write
> that out.
And you mean getting rid of lwlocknames.txt? The impact on dtrace or
other similar tools is uncertain to me because we have free number on
this list, and stuff like GetLWLockIdentifier() rely on the input ID
from lwlocknames.txt.
> Perhaps we should just change the case of the upper-cased names (DSM, SSL,
> WAL, ...) to follow the other names?
So you mean renaming the existing events like WalSenderWaitForWAL to
WalSenderWaitForWal? The impact on existing monitoring queries is not
zero because any changes would be silent, and that's the part that
worried me the most even if it can remove one column in the txt file.
--
Michael