From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Nathan Bossart <nathandbossart@gmail.com>,
        Andres Freund <andres@anarazel.de>,
        Julien Rouhaud <rjuju123@gmail.com>,
        Michael Paquier <michael@paquier.xyz>,
        "Bossart,
    Nathan" <bossartn@amazon.com>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        "wangsh.fnst@fujitsu.com" <wangsh.fnst@fujitsu.com>,
        Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
        Greg Sabino Mullane <htamfids@gmail.com>,
        "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: make MaxBackends available in _PG_init
In-reply-to: <CA+TgmoaN0zj2Km-ZLWnCL_W_x7rrULebDi0yoK=mGyf6yC_cqw@mail.gmail.com>
References: <20220411211435.GA2057981@nathanxps13> <20220412174427.sngj2uexzsttazs2@alap3.anarazel.de> <20220412180306.GA2063516@nathanxps13> <CA+TgmoY4og1VADa78VySwsTjtTQbtXbnRPSq9x=e6ogS_wWfaw@mail.gmail.com> <908945.1649791317@sss.pgh.pa.us> <CA+TgmoZM7=VoAey4rf+sZEKFpGDWhqEqk_MHoBPXkYbAONGcyQ@mail.gmail.com> <20220412195908.GA2064996@nathanxps13> <918045.1649797122@sss.pgh.pa.us> <20220412210745.GB2065815@nathanxps13> <995617.1649799996@sss.pgh.pa.us> <20220412222616.GA2113503@nathanxps13> <CA+TgmoYA09kL2nTKiONj6pCcZ7KNX28YUyseKODJq+trNAXunw@mail.gmail.com> <1088297.1649856441@sss.pgh.pa.us> <CA+TgmoaPC_bpLTfZ8uVuYoV+QNkYztp2BbFNHi_S+VHoChFSpQ@mail.gmail.com> <1095139.1649860995@sss.pgh.pa.us> <CA+TgmoaN0zj2Km-ZLWnCL_W_x7rrULebDi0yoK=mGyf6yC_cqw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 13 Apr 2022 11:25:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1100206.1649864342.1@sss.pgh.pa.us>
Date: Wed, 13 Apr 2022 11:39:02 -0400
Message-ID: <1100207.1649864342@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1100207.1649864342%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> I guess my feeling about this is that _PG_init() is sort of a grab
> bag, and that's not very good. You're supposed to register new GUCs
> there, and request shared memory space, and install any hook functions
> you want to use, and maybe some other stuff. But why is it appropriate
> for all of those things to happen at the same time? I think it pretty
> clearly isn't, and that's why you see _PG_init() functions testing
> process_shared_preload_libraries_in_progress, and why
> RequestAddinShmemSpace() is a no-op if it's not the right time for
> such things. To me, all of that is just a sign that the system is
> badly designed.

Hmm, that's a good point.  If we can replace "RequestAddinShmemSpace
does nothing if called at the wrong time" with "RequestAddinShmemSpace
throws error if called at the wrong time", that seems like a pretty
clear improvement in robustness.

Is there anything else typically done in _PG_init that has to be
conditional on process_shared_preload_libraries_in_progress?  I recall
something about reserving LWLocks, which probably should get the same
treatment.  If we can get to a point where _PG_init shouldn't need to
care about process_shared_preload_libraries_in_progress, because all
the stuff that would care is moved to this new hook, then that would
be very clear cleanup.

			regards, tom lane