public inbox for [email protected]  

help / color / mirror / Atom feed

From: Michael Paquier <[email protected]>
To: Andres Freund <[email protected]>
Cc: Drouvot, Bertrand <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Subject: Re: Autogenerate some wait events code and documentation
Date: Mon, 17 Jul 2023 10:16:02 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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


Attachments:

  [application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
  download

view thread (32+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Autogenerate some wait events code and documentation
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox