Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
David Fetter <david@fetter.org>
From: David Fetter <david@fetter.org>
To: Ian Barwick <ian.barwick@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Stephen Frost <sfrost@snowman.net>, Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-08-05T16:22:03Z
Lists: pgsql-hackers
On Mon, Aug 05, 2019 at 03:52:07PM +0900, Ian Barwick wrote: > On 8/4/19 1:59 AM, Tom Lane wrote:> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > >> On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote: > >>> We're WAY WAY past feature freeze. This isn't the time to rewrite guc.c, > >>> guc-file.l to be suitable for running outside of a backend environment. > > > >> Right. And even if we had the code, it's not quite backpatchable (which > >> we probably should do, considering this is a general ALTER SYSTEM issue, > >> so not pg12-only). > > > >> Not to mention there's no clear consensus this is actually desirable. > >> I'd argue forcing external tools (written in arbitrary language) to use > >> this library (written in C), just to modify a "stupid" text file is a > >> bit overkill. IMO duplicates don't make the file invalid, we should > >> handle that correctly/gracefully, so I don't see why external tools > >> could not simply append to the file. We can deduplicate the file when > >> starting the server, on ALTER SYSTEM, or some other time. > > > > Yup. I'd also point out that even if we had a command-line tool of this > > sort, there would be scenarios where it's not practical or not convenient > > to use. We need not go further than "my tool needs to work with existing > > PG releases" to think of good examples. > > I suspect this hasn't been an issue before, simply because until the removal > of recovery.conf AFAIK there hasn't been a general use-case where you'd need > to modify pg.auto.conf while the server is not running. The use-case which now > exists (i.e. for writing replication configuration) is one where the tool will > need to be version-aware anyway (like pg_basebackup is), so I don't see that as > a particular deal-breaker. > > But... > > > I think we should just accept the facts on the ground, which are that > > some tools modify pg.auto.conf by appending to it > > +1. It's just a text file... So are crontab and /etc/passwd, but there are gizmos that help make it difficult for people to write complete gobbledygook to those. Does it make sense to discuss tooling of that type? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Commits
-
Doc: improve documentation about postgresql.auto.conf.
- e3ddb112f245 10.11 landed
- 7f77f2aec3d0 11.6 landed
- 57980bdf62f4 9.4.25 landed
- 45aaaa42fefa 13.0 landed
- 372d6a8918e0 12.0 landed
- 1ab92aaa97ce 9.5.20 landed
- 0969a7aa3240 9.6.16 landed
-
Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf.
- f1bf619acdff 13.0 landed
- f8c9a08520ee 10.11 landed
- a4b0d955bd23 9.4.25 landed
- 75b2f011f642 12.0 landed
- 4784ad7a370e 9.6.16 landed
- 32d38f54a369 11.6 landed
- 29f9b1819a72 9.5.20 landed