Re: make MaxBackends available in _PG_init

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "wangsh(dot)fnst(at)fujitsu(dot)com" <wangsh(dot)fnst(at)fujitsu(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: make MaxBackends available in _PG_init
Date: 2022-01-29 05:24:24
Message-ID: YfTPiPDp7WoS6lBu@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 28, 2022 at 08:33:42PM -0800, Nathan Bossart wrote:
> Hm. Perhaps we should understand the full scope of the problem first.
> What else besides MaxBackends and the shared memory GUCs won't be properly
> initialized when the shared_preload_libraries' _PG_init() functions are
> called? MaxBackends seems to be the only one that folks have experienced
> problems with, which is why I initially zeroed in on it.

Yeah, it would be good to know the scope before defining the limits
of what could be done. Another thing may be the interactions with
session_preload_libraries and local_preload_libraries.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-01-29 06:38:53 Re: GUC flags
Previous Message Julien Rouhaud 2022-01-29 05:19:46 Re: Schema variables - new implementation for Postgres 15