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)
