Re: Support to define custom wait events for extensions

On 2023-08-14 15:28, Michael Paquier wrote:
> On Mon, Aug 14, 2023 at 12:31:05PM +0900, Masahiro Ikeda wrote:
>> Thanks! I confirmed the changes, and all tests passed.
>
> Okay, cool. I got some extra time today and applied that, with a few
> more tweaks.

Thanks for applying master branch!

> This looks correct, but perhaps we need to think harder about the
> custom event names and define a convention when more of this stuff is
> added to the core modules.

I checked the source code how many functions use WAIT_EVENT_EXTENSION.
There are 3 contrib modules and a test module use WAIT_EVENT_EXTENSION
and
there are 8 places where it is called as an argument.

* dblink
- dblink_get_conn(): the wait event is set until the connection
establishment succeeded
- dblink_connect(): same as above

* autoprewarm
- autoprewarm_main(): the wait event is set until shutdown request is
received
- autoprewarm_main(): the wait event is set until the next dump time

* postgres_fdw
- connect_pg_server(): the wait event is set until connection
establishment succeeded
- pgfdw_get_result(): the wait event is set until the results are
received
- pgfdw_get_cleanup_result(): same as above except for abort cleanup

* test_sh_mq
- wait_for_workers_to_become_ready(): the wait event is set until the
workers become ready

I'm thinking a name like "contrib name + description summary" would
be nice. The "contrib name" is namespace-like and the "description
summary"
is the same as the name of the waiting event name in core. For example,
"DblinkConnect" for dblink. In the same as the core one, I thought the
name
should be the camel case.

BTW, is it better to discuss this in a new thread because other
developers
might be interested in user-facing wait event names? I also would like
to add
documentation on the wait events for each modules, as they are not
mentioned now.

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION