Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
От | Ian Barwick |
---|---|
Тема | Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions |
Дата | |
Msg-id | e61fca0f-7ea7-d8bf-6230-a35e8f9a0911@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: