|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Set arbitrary GUC options during initdb|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2023-01-25 16:25:19 -0500, Tom Lane wrote:
> The attached patch responds to the discussion at  about how
> we ought to offer a way to set any server GUC from the initdb
> command line.
Are you thinking of backpatching this, to offer the people affected by the
issue in  a way out?
> So this invents an initdb switch "-c NAME=VALUE" just like the
> one that the server itself has long had.
I still am +1 on the idea. I've actually wanted this for development purposes
a couple times...
> The specified settings are applied on the command line of the initial probe
> calls (which happen before we've made any config files), and then they are
> added to postgresql.auto.conf, which causes them to take effect for the
> bootstrap backend runs as well as subsequent postmaster starts.
I think this means that if you set e.g. max_connections as an initdb
parameter, the probes won't do much. Probably fine?
Perhaps worth memorializing the priority of the -c options in a test?
E.g. setting shared_buffers = 20MB or so and then testing that that's the
value when starting the server?
> I also invented "--set NAME=VALUE", mainly because just about
> every other initdb switch has a long form. The server itself
> doesn't have that spelling, so I'm not wedded to that part.
Fine with me, but also fine to leave out.
|Next Message||Isaac Morland||2023-01-25 22:17:59||Re: Re: Support plpgsql multi-range in conditional control|
|Previous Message||Andres Freund||2023-01-25 21:58:01||Re: pgsql: Rename contrib module basic_archive to basic_wal_module|