Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

On Tue, May 16, 2023 at 1:14 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Mon, May 15, 2023 at 06:01:02PM -0700, Andres Freund wrote:
> > Why those tweaks are necessary is precisely what I am asking for.
>
> Then the perl script generates the same structures for all the wait
> event classes, with all the events associated to that. There may be a
> point in keeping extension and buffer pin out of this refactoring, but
> reworking these like that moves in a single place all the wait event
> definitions, making future additions easier. Buffer pin actually
> needed a small rename to stick with the naming rules of the other
> classes.
>
+1 (Nice explanation, Improving things, Consistency. Always good)

>
> These are the two things refactored in the patch, explaining the what.
> The reason behind the why is to make the script in charge of
> generating all these structures and functions consistent for all the
> wait event classes, simply. Treating all the wait event classes
> together eases greatly the generation of the documentation, so that it
> is possible to enforce an ordering of the tables of each class used to
> list each wait event type attached to them. Does this explanation
> make sense?
>
+1 (To me, but I am not important. But having this saved in the thread!!!)

>
> Lock and LWLock are funkier because of the way they grab wait events
> for the inner function, still these had better have their
> documentation generated so as all the SGML tables created for all the
> wait event tables are ordered alphabetically, in the same way as
> HEAD.
> --
> Michael
>
+1 (Whatever helps automate/generate the docs)

Kirk...