Re: Set arbitrary GUC options during initdb

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Set arbitrary GUC options during initdb
Date: 2023-01-27 15:24:16
Message-ID: CAMsGm5ciem-sWuDoAwmww1grCvdNrq17KJQ4dxhdvZ2911aOuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 27 Jan 2023 at 09:49, Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:

> On 25.01.23 22:25, Tom Lane wrote:
> > So this invents an initdb switch "-c NAME=VALUE" just like the
> > one that the server itself has long had.
>
> This seems useful.
>
> > 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?
>

That would be my expectation also. I believe that is how it works now for
options which can be set by initdb, such as locale and port. I view
postgresql.auto.conf being for temporary changes, or changes related to
different instances within a replication setup, or whatever other uses
people come up with - but not for the permanent configuration established
by initdb.

In particular, I would be surprised if removing a postgresql.auto.conf
completely disabled an instance. Obviously, in my replication setup
example, the replication would be broken, but the basic operation of the
instance would still be possible.

Also, if somebody wants to put a change in postgresql.auto.conf, they can
easily do it using ALTER SYSTEM once the instance is running, or by just
writing out their own postgresql.auto.conf before starting it. Putting a
change in postgresql.conf programmatically is a bit of a pain.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-01-27 15:26:01 Re: Named Operators
Previous Message Dmitry Dolgov 2023-01-27 15:18:41 Re: Lazy JIT IR code generation to increase JIT speed with partitions