public inbox for [email protected]
help / color / mirror / Atom feedFrom: Julien Rouhaud <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Bossart, Nathan <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Greg Sabino Mullane <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: make MaxBackends available in _PG_init
Date: Thu, 14 Apr 2022 13:50:24 +0800
Message-ID: <Yle2IBsS1Nnp2WWa@jrouhaud> (raw)
In-Reply-To: <20220413183040.GA2116671@nathanxps13>
References: <20220412222616.GA2113503@nathanxps13>
<CA+TgmoYA09kL2nTKiONj6pCcZ7KNX28YUyseKODJq+trNAXunw@mail.gmail.com>
<[email protected]>
<CA+TgmoaPC_bpLTfZ8uVuYoV+QNkYztp2BbFNHi_S+VHoChFSpQ@mail.gmail.com>
<[email protected]>
<CA+TgmoaN0zj2Km-ZLWnCL_W_x7rrULebDi0yoK=mGyf6yC_cqw@mail.gmail.com>
<[email protected]>
<CA+TgmobVwPLaEq9UrKtnaoQiA+2LQg+NS8ANhXNGNBf+c_yvRw@mail.gmail.com>
<[email protected]>
<20220413183040.GA2116671@nathanxps13>
On Wed, Apr 13, 2022 at 11:30:40AM -0700, Nathan Bossart wrote:
> On Wed, Apr 13, 2022 at 12:05:08PM -0400, Tom Lane wrote:
> > Robert Haas <[email protected]> writes:
> >> It may be too much to hope that we're going to completely get rid of
> >> process_shared_preload_libraries_in_progress tests.
> >
> > Perhaps, but this is definitely an area that could stand to have some
> > serious design thought put into it. You're quite right that it's
> > largely a mess today, but I think proposals like "forbid setting GUCs
> > during _PG_init" would add to the mess rather than clean things up.
>
> +1. The simplest design might be to just make a separate preload hook.
> _PG_init() would install hooks, and then this preload hook would do
> anything that needs to happen when the library is loaded via s_p_l.
> However, I think we still want a new shmem request hook where MaxBackends
> is initialized.
Yeah this one seems needed no matter what.
> If we do move forward with the shmem request hook, do we want to disallow
> shmem requests anywhere else, or should we just leave it up to extension
> authors to do the right thing? Many shmem requests in _PG_init() are
> probably okay unless they depend on MaxBackends or another GUC that someone
> might change. Given that, I think I currently prefer the latter (option B
> from upthread).
I'd be in favor of a hard break. There are already multiple extensions that
relies on non final value of GUCs to size their shmem request. And as an
extension author it can be hard to realize that, as those extensions work just
fine until someone wants to try it with some other extension that changes some
GUC. Forcing shmem request in a new hook will make sure that it's *always*
correct, and that only requires very minimal work on the extension side.
view thread (94+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: make MaxBackends available in _PG_init
In-Reply-To: <Yle2IBsS1Nnp2WWa@jrouhaud>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox