Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Date
Msg-id ZIJhEhRkAGavghW6@paquier.xyz
Whole thread Raw
In response to Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Responses Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
List 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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15
Next
From: Stephan Doliov
Date:
Subject: Re: Let's make PostgreSQL multi-threaded