On Thu, Apr 14, 2022 at 12:39:46PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Apr 14, 2022 at 12:22 PM Nathan Bossart
>> <nathandbossart@gmail.com> wrote:
>>>> I'd be in favor of a hard break.
>
>>> Yeah, this is a good point. If we're okay with breaking existing
>>> extensions like this, I will work on a patch.
>
>> I tend to think it's a good idea.
>
> I've come around to that view as well.
Here is a new patch set that introduces the aforementioned "hard break."
I noticed that requests for more LWLocks follow a similar pattern as
regular shared memory requests, and I figured that we would want to do
something similar for those, but I wasn't sure exactly how to proceed. I
saw two options: 1) use shmem_request_hook for both regular requests and
LWLock requests or 2) introduce an lwlock_request_hook. My instinct was
that option 1 was preferable, but AFAICT this requires introducing a new
external variable for inspecting whether the request is made at a valid
time. This would be similar to
process_shared_preload_libraries_in_progress, which I believe means a
determined extension author could easily hack around the request
restrictions. I thought option 2 added too much machinery to work around
this problem. For now, I haven't made any changes for LWLock requests.
What are your thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
