From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Autogenerate some wait events code and documentation |
Date: | 2023-07-07 01:19:43 |
Message-ID: | 20230707011943.qxbj3vj2iwsfgqvq@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-07-06 09:36:12 +0900, Michael Paquier wrote:
> 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?
No, I meant the second column in wait_event_names.txt. If you look at stuff
like:
WAIT_EVENT_ARCHIVER_MAIN "ArchiverMain" "Waiting in main loop of archiver process."
It'd be pretty trivial to generate ArchiverMain from ARCHIVER_MAIN.
> 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.
I don't really care, tbh. If we wanted to keep the names the same in case of
abbreviations, we could just make the name optional, and auto-generated if not
explicitly specified.
> > 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?
Yes.
> 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.
Then let's just use - or so to indicate the inferred name, with a "string"
overriding it?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-07-07 01:39:27 | Re: Fix search_path for all maintenance commands |
Previous Message | Paul A Jungwirth | 2023-07-07 01:03:37 | Re: SQL:2011 application time |