On 8/3/19 7:56 AM, Andres Freund wrote:
> Hi,
>
> On 2019-08-02 18:47:07 -0400, Tom Lane wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>>> I disagree that this should only be addressed in alter system, as I’ve said
>>> before and as others have agreed with. Having one set of code that can be
>>> used to update parameters in the auto.conf and then have that be used by
>>> pg_basebackup, alter system, and external tools, is the right approach.
>>
>> I don't find that to be necessary or even desirable. Many (most?) of the
>> situations where this would be important wouldn't have access to a running
>> backend, and maybe not to any PG code at all --- what if your tool isn't
>> written in C?
>
> I think a commandline tool to perform the equivalent of ALTER SYSTEM on
> a shutdown cluster would be a great tool. It's easy enough to add
> something with broken syntax, and further down the road such a tool
> could not only ensure the syntax is correct, but also validate
> individual settings as much as possible (obviously there's some hairy
> issues here).
What I came up with shoehorned a stripped-down version of the backend
config parser into fe_utils and provides a function to modify pg.auto.conf
in much the same way ALTER SYSTEM does, but with only the basic syntax
checking provided by the parser of course. And for completeness a
client utility which can be called by scripts etc.
I can clean it up and submit it later for reference (got distracted by other things
recently) though I don't think it's a particularly good solution due to the
lack of actual checks for the provided GUCSs (and the implementation
is ugly anyway); something like what Andres suggests below would be far better.
> Quite possibly the most realistic way to implement something like that
> would be a postgres commandline switch, which'd start up far enough to
> perform GUC checks and execute AlterSystem(), and then shut down
> again. We already have -C, I think such an option could reasonably be
> implemented alongside it.
>
> Obviously this is widely out of scope for v12.
Regards
Ian Barwick
--
Ian Barwick https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services