Re: Support to define custom wait events for extensions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support to define custom wait events for extensions
Дата
Msg-id ZK5QrVpF4G52SApK@paquier.xyz
обсуждение исходный текст
Ответ на Re: Support to define custom wait events for extensions  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Jul 11, 2023 at 05:36:47PM -0700, Andres Freund wrote:
> On 2023-07-11 16:45:26 +0900, Michael Paquier wrote:
>> +$node->init;
>> +$node->append_conf(
>> +    'postgresql.conf',
>> +    "shared_preload_libraries = 'test_custom_wait_events'"
>> +);
>> +$node->start;
>
> I think this should also test registering a wait event later.

Yup, agreed that the coverage is not sufficient.

> > @@ -0,0 +1,188 @@
> > +/*--------------------------------------------------------------------------
> > + *
> > + * test_custom_wait_events.c
> > + *        Code for testing custom wait events
> > + *
> > + * This code initializes a custom wait event in shmem_request_hook() and
> > + * provide a function to launch a background worker waiting forever
> > + * with the custom wait event.
>
> Isn't this vast overkill?  Why not just have a simple C function that waits
> with a custom wait event, until cancelled? That'd maybe 1/10th of the LOC.

Hmm.  You mean in the shape of a TAP test where a backend registers a
wait event by itself in a SQL function that waits for a certain amount
of time with a WaitLatch(), then we use a second poll_query_until()
that checks if the a wait event is stored in pg_stat_activity?  With
something like what's done at the end of 001_stream_rep.pl, that
should be stable, I guess..
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Wen Yi"
Дата:
Сообщение: Re: [PATCH]Add a tip to the check mode
Следующее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL