On Tue Jul 11, 2023 at 6:29 PM CDT, Michael Paquier wrote:
> On Tue, Jul 11, 2023 at 12:39:52PM -0500, Tristan Partin wrote:
> > Given the context of our last conversation, I assume this code was
> > copied from somewhere else. Since this is new code, I think it would
> > make more sense if newalloc was a uint16 or size_t.
>
> 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.
> > From what I understand, Neon differs from upstream in some way related
> > to this patch. I am trying to ascertain how that is. I hope to provide
> > more feedback when I learn more about it.
>
> 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
--
Tristan Partin
Neon (https://neon.tech)