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
