pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Drouvot, Bertrand <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Autogenerate some wait events code and documentation
Date: Tue, 11 Jul 2023 06:54:23 +0200
Message-ID: <c301e8fc-aee3-d71e-ae66-a6c65f06d114@gmail.com> (raw)
In-Reply-To: <ZKyLvXMS/D3hMFj4@paquier.xyz>
References: <ZKo4b1bDI5+FoTex@paquier.xyz>
	<20230710071136.jiedze443q7o5vsp@alvherre.pgsql>
	<ZKyLvXMS/D3hMFj4@paquier.xyz>



On 7/11/23 12:52 AM, Michael Paquier wrote:
> On Mon, Jul 10, 2023 at 09:11:36AM +0200, Alvaro Herrera wrote:
>> I don't like this bit, because it means the .txt file is now ungreppable
>> as source of the enum name.  Things become mysterious and people have to
>> track down the event name by reading the the Perl generating script.
>> It's annoying.  I'd rather have the extra column, even if it means a
>> little duplicity.
> 
> Hmm.  I can see your point that we'd lose the direct relationship
> between the enum and string when running a single `git grep` from the
> tree, still attempting to do that does not actually lead to much
> information gained?  Personally, I usually grep for code when looking
> for consistent information across various paths in the tree.  Wait
> events are very different: each enum is used in a single place in the
> tree making their grep search the equivalent of looking at
> wait_event_names.txt anyway?
> 

Before commit fa88928470 one could find the relationship between the enum and the name
in wait_event.c (a simple git grep would provide it).

With commit fa88928470 in place, one could find the relationship between the enum and the name
in wait_event_names.txt (a simple git grep would provide it).

With the proposal we are discussing here, once the build is done and so the pgstat_wait_event.c
file is generated then we have the same "grep" capability than pre commit fa88928470 (except that
"git grep" can't be used and one would need things like
find . -name "*.c" -exec grep -il "WAIT_EVENT_CHECKPOINTER_MAIN" {} \;)

I agree that it is less "obvious" than pre fa88928470 but still doable though.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com





view thread (77+ messages)  latest in thread

Message-ID: <c301e8fc-aee3-d71e-ae66-a6c65f06d114@gmail.com>
Permalink:  ../c301e8fc-aee3-d71e-ae66-a6c65f06d114@gmail.com/
Also on:    postgresql.org/message-id/c301e8fc-aee3-d71e-ae66-a6c65f06d114@gmail.com

 · 

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: pgsql-hackers@postgresql.org
  Cc: bertranddrouvot.pg@gmail.com, michael@paquier.xyz, alvherre@alvh.no-ip.org, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
  Subject: Re: Autogenerate some wait events code and documentation
  In-Reply-To: <c301e8fc-aee3-d71e-ae66-a6c65f06d114@gmail.com>

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

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