Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Дата
Msg-id ZIJhEhRkAGavghW6@paquier.xyz
обсуждение исходный текст
Ответ на Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Ответы Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Список pgsql-hackers
On Thu, Jun 08, 2023 at 10:57:55AM +0900, Masahiro Ikeda wrote:
> (Excuse me for cutting in, and this is not directly related to the thread.)
> +1. I'm interested in the feature.
>
> This is just a example and it probable be useful for other users. IMO, at
> least, it's better to improve the specification that "Extension"
> wait event type has only the "Extension" wait event.

I hope that nobody would counter-argue you here.  In my opinion, we
should just introduce an API that allows extensions to retrieve wait
event numbers that are allocated by the backend under
PG_WAIT_EXTENSION, in a fashion similar to GetNamedLWLockTranche().
Say something like:
int GetExtensionWaitEvent(const char *wait_event_name);

I don't quite see a design where extensions could rely on their own
numbers statically assigned by the extension maintainers, as this is
most likely going to cause conflicts.  And I would guess that a lot of
external code would want to get more data pushed to pg_stat_activity,
meaning a lot of conflicts, potentially.
--
Michael

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15
Следующее
От: Stephan Doliov
Дата:
Сообщение: Re: Let's make PostgreSQL multi-threaded