Re: Set arbitrary GUC options during initdb

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Set arbitrary GUC options during initdb
Дата
Msg-id 20230125220339.vdukiow6rvbtr7a2@awork3.anarazel.de
обсуждение исходный текст
Ответ на Set arbitrary GUC options during initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Set arbitrary GUC options during initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2023-01-25 16:25:19 -0500, Tom Lane wrote:
> The attached patch responds to the discussion at [1] 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 [1] 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.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: Rename contrib module basic_archive to basic_wal_module
Следующее
От: Isaac Morland
Дата:
Сообщение: Re: Re: Support plpgsql multi-range in conditional control