Hi,
On 4/27/23 8:13 AM, Michael Paquier wrote:
> 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.
>
Right.
> 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.
Agree that it would fix the doc ordering and that we could do that.
It's done that way in V6.
There is already comments about this in lockfuncs.c and lwlocknames.txt, so
V6 updates those comments accordingly.
> 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)
>
Agree, done in V6.
> 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.
Right, done that way in V6.
Please note that it creates 2 new "wait events": WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN.
Then, they replace PG_WAIT_EXTENSION and PG_WAIT_BUFFER_PIN (resp.) where appropriate.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
