Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

From: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Date: 2023-06-09 09:20:09
Message-ID: bc51ad5e9547615cc195abd67af34a89@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-06-09 13:26, Drouvot, Bertrand wrote:
> Hi,
>
> On 6/9/23 1:15 AM, Michael Paquier wrote:
>> 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);
>
> +1, that's something I've in mind to work on once/if this patch is/get
> committed.

Thanks for replying. If you are ok, I'll try to make a patch
to allow extensions to define custom wait events.

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2023-06-09 09:51:14 Re: Support logical replication of DDLs
Previous Message Daniel Verite 2023-06-09 09:18:41 Re: Inconsistent results with libc sorting on Windows