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