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