Re: Set arbitrary GUC options during initdb

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Set arbitrary GUC options during initdb
Date: 2023-01-25 22:03:39
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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, 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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
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