public inbox for [email protected]  

help / color / mirror / Atom feed

From: Michael Paquier <[email protected]>
To: Drouvot, Bertrand <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Autogenerate some wait events code and documentation
Date: Sat, 6 May 2023 11:23:17 +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 Thu, May 04, 2023 at 08:39:49AM +0200, Drouvot, Bertrand wrote:
> On 5/1/23 1:59 AM, Michael Paquier wrote:
> I'm not sure I like it. First, it does break the "Note" ordering as compare
> to the current documentation. That's not a big deal though.
> 
> Secondly, what If we need to add some note(s) in the future for
> another wait class? Having all the notes after all the tables are
> generated would sound weird to me.

Appending these notes at the end of all the tables does not strike me
as a big dea, TBH.  But, well, my sole opinion is not the final choice
either.  For now, I am mostly tempted to keep the generation script as
minimalistic as possible.

> We could discuss another approach for the "Note" part if there is a
> need to add one for an existing/new wait class though.

Documenting what's expected from the wait event classes is critical in
the .txt file as that's what developers are going to look at when
adding a new wait event.  Adding them in the header is less appealing
to me considering that is it now generated, and the docs provide a lot
of explanation as well.

>> This has as extra consequence to require a change in
>> wait_event.h so as PG_WAIT_BUFFER_PIN is renamed to PG_WAIT_BUFFERPIN,
>> equally fine by me.  Logically, this rename should be done in a patch
>> of its own, for clarity.
> 
> Yes, I can look at it.
> [...]
> Agree, I'll look at this.

Thanks!

> I'll look at v7 when the v17 branch opens and propose the separate patch
> mentioned above at that time too.

Thanks, again.
--
Michael


Attachments:

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

view thread (23+ 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]
  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