Re: Support worker_spi to execute the function dynamically. - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Support worker_spi to execute the function dynamically.
Date
Msg-id CALj2ACVOCiXirZFRL-gi7mV2zgdH4e3-vyJQx2fxdzycJTv3qg@mail.gmail.com
Whole thread Raw
In response to Re: Support worker_spi to execute the function dynamically.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Support worker_spi to execute the function dynamically.
List pgsql-hackers
On Thu, Jul 20, 2023 at 9:25 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> > In my understanding, the restriction is not required. So, I think it's
> > better to change the behavior.
> > (v1-0001-Support-worker_spi-to-execute-the-function-dynamical.patch)
> >
> > What do you think?
>
> +1.  I'm OK to lift this restriction with a SIGHUP GUC for the
> database name and that's not a pattern to encourage in a template
> module.  Will do so, if there are no objections.

+1. However, a comment above helps one to understand why some GUCs are
defined before if (!process_shared_preload_libraries_in_progress). As
this is an example extension, it will help understand the reasoning
better. I know we will it in the commit message, but a direct comment
helps:

    /*
     * Note that this GUC is defined irrespective of worker_spi shared library
     * presence in shared_preload_libraries. It's possible to create the
     * worker_spi extension and use functions without it being specified in
     * shared_preload_libraries. If we return from here without defining this
     * GUC, the dynamic workers launched by worker_spi_launch() will keep
     * crashing and restarting.
     */

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: mao zhang
Date:
Subject: Re: FATAL: operator class "xxxx" does not exist for access method "btree"