Re: Support to define custom wait events for extensions - Mailing list pgsql-hackers

Thanks for continuing to work on this patchset. I only have
prose-related comments.

> To support custom wait events, it add 2 APIs to define new wait events
> for extensions dynamically.

Remove the "it" here.

> The APIs are
> * WaitEventExtensionNew()
> * WaitEventExtensionRegisterName()

> These are similar to the existing LWLockNewTrancheId() and
> LWLockRegisterTranche().

This sentence seems like it could be removed given the API names have
changed during the development of this patch.

> First, extensions should call WaitEventExtensionNew() to get one
> or more new wait event, which IDs are allocated from a shared
> counter.  Next, each individual process can use the wait event with
> WaitEventExtensionRegisterName() to associate that a wait event
> string to the associated name.

This portion of the commit message is a copy-paste of the function
comment. Whatever you do in the function comment (which I commented on
below), just do here as well.

> +     so an wait event might be reported as just <quote><literal>extension</literal></quote>
> +     rather than the extension-assigned name.

s/an/a

> +   <sect2 id="xfunc-addin-wait-events">
> +    <title>Custom Wait Events for Add-ins</title>

This would be the second use of "Add-ins" ever, according to my search.
Should this be "Extensions" instead?

> +    <para>
> +    Add-ins can define custom wait events that the wait event type is

s/that/where

> +    <literal>Extension</literal>.
> +    </para>
> +    <para>
> +    First, add-ins should get new one or more wait events by calling:

"one or more" doesn't seem to make sense grammatically here.

> +<programlisting>
> +    uint32 WaitEventExtensionNew(void)
> +</programlisting>
> +    Next, each individual process can use them to associate that

Remove "that".

> +    a wait event string to the associated name by calling:
> +<programlisting>
> +    void WaitEventExtensionRegisterName(uint32 wait_event_info, const char *wait_event_name);
> +</programlisting>
> +    An example can be found in
> +    <filename>src/test/modules/test_custom_wait_events/test_custom_wait_events.c</filename>
> +    in the PostgreSQL source tree.
> +    </para>
> +   </sect2>

> + * Register a dynamic wait event name for extension in the lookup table
> + * of the current process.

Inserting an "an" before "extension" would make this read better.

> +/*
> + * Return the name of an wait event ID for extension.
> + */

s/an/a

> +       /*
> +        * It's an user-defined wait event, so look in WaitEventExtensionNames[].
> +        * However, it's possible that the name has never been registered by
> +        * calling WaitEventExtensionRegisterName() in the current process, in
> +        * which case give up and return "extension".
> +        */

s/an/a

"extension" seems very similar to "Extension". Instead of returning a
string here, could we just error? This seems like a programmer error on
the part of the extension author.

> + * Extensions can define their wait events. First, extensions should call
> + * WaitEventExtensionNew() to get one or more wait events, which IDs are
> + * allocated from a shared counter.  Next, each individual process can use
> + * them with WaitEventExtensionRegisterName() to associate that a wait
> + * event string to the associated name.

An "own" before "wait events" in the first sentence would increase
clarity. "where" instead of "which" in the next sentence. Remove "that"
after "associate" in the third sentence.

--
Tristan Partin
Neon (https://neon.tech)