Re: Autogenerate some wait events code and documentation - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Autogenerate some wait events code and documentation
Date
Msg-id ZEoSlv9HxURD8Uxw@paquier.xyz
Whole thread Raw
In response to Re: Autogenerate some wait events code and documentation  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: Autogenerate some wait events code and documentation  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Wed, Apr 26, 2023 at 08:36:44PM +0200, Drouvot, Bertrand wrote:
> Please find attached V5 addressing the previous comments except
> the "ordering" one (need to look deeper at this).

I was putting my hands into that, and I see now what you mean here..
Among the nine types of wait events, Lock, LWLock, BufferPin and
Extension don't get generated at all.

Generating the contents of Lock would mean to gather in a single file
the data for the generation of LockTagType in lock.h, the list of
LockTagTypeNames in lockfuncs.c and the description of the docs.  This
data being spread across three files is not really appealing to make
that generated..  LWLocks would mean to either extend lwlocknames.txt
with the description from the docs if we were to centralize the whole
thing.

But do we need to merge more data than necessary?  We could do things
in the simplest fashion possible while making the docs and code
user-friendly in the ordering: just add a section for Lock and LWLocks
in waiteventnames.txt with an extra comment in their headers and/or
data files to tell that waiteventnames.txt also needs a refresh.  I
would be tempted to do that, actually, and force an ordering for all
the wait event categories in generate-waiteventnames.pl with something
like that:
 # Generate the output files
-foreach $waitclass (keys %hashwe)
+foreach $waitclass (sort keys %hashwe)

BufferPin and Extension don't really imply an extra cost by the way:
they could just be added to the txt for the wait events even if they
have one single element for now.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: pg_recvlogical prints bogus error when interrupted
Next
From: Michael Paquier
Date:
Subject: Re: pg_recvlogical prints bogus error when interrupted