Re: Support to define custom wait events for extensions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support to define custom wait events for extensions
Date
Msg-id ZLhy7ct0o0LQBUR4@paquier.xyz
Whole thread Raw
In response to Re: Support to define custom wait events for extensions  ("Tristan Partin" <tristan@neon.tech>)
List pgsql-hackers
On Wed, Jul 19, 2023 at 11:16:34AM -0500, Tristan Partin wrote:
> On Tue Jul 11, 2023 at 6:29 PM CDT, Michael Paquier wrote:
>> This style comes from LWLockRegisterTranche() in lwlock.c.  Do you
>> think that it would be more adapted to change that to
>> pg_nextpower2_size_t() with a Size?  We could do that for the existing
>> code on HEAD as an improvement.
>
> Yes, I think that would be the most correct code. At the very least,
> using a uint32 instead of an int, would be preferrable.

Would you like to send a patch on a new thread about that?

>> Hmm, okay, that would nice to hear about to make sure that the
>> approach taken on this thread is able to cover what you are looking
>> for.  So you mean that Neon has been using something similar to
>> register wait events in the backend?  Last time I looked at the Neon
>> repo, I did not get the impression that there was a custom patch for
>> Postgres in this area.  All the in-core code paths using
>> WAIT_EVENT_EXTENSION would gain from the APIs added here, FWIW.
>
> I did some investigation into the Neon fork[0], and couldn't find any
> commits that seemed related. Perhaps this is on our wishlist instead of
> something we already have implemented. I have CCed Heikki to talk some
> more about how this would fit in at Neon.
>
> [0]: https://github.com/neondatabase/postgres

Anybody with complex out-of-core extensions have wanted more
monitoring capabilities for wait events without relying on the core
backend.  To be honest, I would not be surprised to see this stuff on
more than one wishlist.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Support SK_SEARCHNULL / SK_SEARCHNOTNULL for heap-only scans