Re: Set arbitrary GUC options during initdb

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 25.01.23 22:25, Tom Lane wrote:
>> 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 would have expected them to be edited into postgresql.conf. What are
> the arguments for one or the other?

TBH, the driving reason was that the string-munging code we have in
initdb isn't up to snuff for that: it wants to substitute for an
exactly-known string, which we won't have in the case of an
arbitrary GUC.

One idea if we want to make it work like that could be to stop
trying to edit out the default value, and instead make the file
contents look like, say,

#huge_pages = try # on, off, or try
huge_pages = off # set by initdb

Then we just need to be able to find the GUC's entry.

> Btw., something that I have had in my notes for a while, but with this
> it would now be officially exposed: Not all options can be safely set
> during bootstrap. For example,
> initdb -D data -c track_commit_timestamp=on
> will fail an assertion. This might be an exception, or there might be
> others.

Interesting. We'd probably want to sprinkle some more
do-nothing-in-bootstrap-mode tests as we discover that sort of thing.

regards, tom lane