Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8; format=Flowed
Date: Wed, 19 Jul 2023 11:16:34 -0500
Message-Id: <CU6A7YZ6ZLPH.2Z52EGRWXQ1K4@gonk>
Cc: "Masahiro Ikeda" <ikedamsh@oss.nttdata.com>,
 <pgsql-hackers@lists.postgresql.org>, <hlinnaka@iki.fi>
Subject: Re: Support to define custom wait events for extensions
To: "Michael Paquier" <michael@paquier.xyz>
From: "Tristan Partin" <tristan@neon.tech>
References: <b9f5411acda0cf15c8fbb767702ff43e@oss.nttdata.com>
 <CTDCV6CIJAKR.TQOTL86K9628@gonk>
 <e4cef41ee00f791c2264f871dc6b5b19@oss.nttdata.com>
 <CTE7JPUIMMBL.2YLT1IWHPUDZ8@gonk>
 <a9eae9af-3834-ceed-33bc-d36c914fef53@oss.nttdata.com>
 <135feae32cd28f9fb555fe46acb939a0@oss.nttdata.com>
 <f3c10c343e6a6080a6b57f0ed25d9e52@oss.nttdata.com>
 <CTZIZDTI9J08.1WLW5E0FWL7LV@gonk> <ZK3l5pLoCF7q4CHo@paquier.xyz>
In-Reply-To: <ZK3l5pLoCF7q4CHo@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/CU6A7YZ6ZLPH.2Z52EGRWXQ1K4%40gonk>
Precedence: bulk

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

--=20
Tristan Partin
Neon (https://neon.tech)