Re: Set arbitrary GUC options during initdb

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Set arbitrary GUC options during initdb
Дата
Msg-id 2852155.1674685274@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Set arbitrary GUC options during initdb  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> 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?

We could ... it's a new feature for sure, but it seems quite unlikely
to break things for anybody not using it.

>> 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?

Right, the probed value will be overridden.

> 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?

Given that it's written into postgresql.auto.conf, I imagine that
we have test coverage of that point already.

There is a more subtle issue, which is that -c max_connections or
-c shared_buffers should override the probe values *during the
probe steps*.  My first thought about implementation had been to
create postgresql.auto.conf right off the bat, but that would
fail to have this property because server command line overrides
config file.  I can't think of any very portable way to check
that though.

            regards, tom lane



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

Предыдущее
От: Isaac Morland
Дата:
Сообщение: Re: Re: Support plpgsql multi-range in conditional control
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent