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
|
Список | 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 по дате отправления: