Re: make MaxBackends available in _PG_init - Mailing list pgsql-hackers

From Robert Haas
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id CA+TgmoZRnwF=9tMX0TiqZGC4qAK_27NweKd5r-S=OSaE_nL70A@mail.gmail.com
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
Re: make MaxBackends available in _PG_init  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Sat, Apr 9, 2022 at 9:24 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > FWIW I would be on board with reverting all the GetMaxBackends() stuff if
> > we made the value available in _PG_init() and stopped supporting GUC
> > overrides by extensions (e.g., ERROR-ing in SetConfigOption() when
> > process_shared_preload_libraries_in_progress is true).
>
> Yeah I would prefer this approach too, although it couldn't prevent extension
> from directly modifying the underlying variables so I don't know how effective
> it would be.

I think I also prefer this approach. I am willing to be convinced
that's the wrong idea, but right now I favor it.

> On the bright side, I see that citus is using SetConfigOption() to increase
> max_prepared_transactions [1].  That's the only extension mentioned in that
> thread that does modify some GUC, and this GUC was already marked as
> PGDLLIMPORT since 2017 so it probably wasn't done that way for Windows
> compatibility reason.

I don't quite understand this, but I think if we want to support this
kind of thing it needs a separate hook.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: CLUSTER on partitioned index
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery