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
signature.asc
Description: PGP signature
