Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ian Barwick <ian.barwick@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-06-22T22:02:45Z
Lists: pgsql-hackers
Greetings, On Sat, Jun 22, 2019 at 17:43 Amit Kapila <amit.kapila16@gmail.com> wrote: > On Sun, Jun 23, 2019 at 2:43 AM Stephen Frost <sfrost@snowman.net> wrote: > > > > Greetings, > > > > On Sat, Jun 22, 2019 at 17:07 Amit Kapila <amit.kapila16@gmail.com> > wrote: > >> > >> On Fri, Jun 21, 2019 at 8:15 PM Robert Haas <robertmhaas@gmail.com> > wrote: > >> > > >> > On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick > >> > <ian.barwick@2ndquadrant.com> wrote: > >> > > In Pg12, the code in pg_basebackup implies the correct thing to do > is append to .auto.conf, > >> > > but as demonstrated that can cause problems with duplicate entries. > >> > > >> > Yeah. > >> > > >> > To me, forcing every tools author to use postgresql.conf parsing tools > >> > rather than just appending to the file is a needless burden on tool > >> > authors. > >> > > >> > >> OTOH, if we give license to all the tools that they can append to the > >> .auto.conf file whenever they want, then, I think the contents of the > >> file can be unpredictable. Basically, as of now, we allow only one > >> backend to write to the file, but giving a free pass to everyone can > >> create a problem. This won't be a problem for pg_basebackup, but can > >> be for other tools. > > > > > > I don’t think anyone was suggesting that tools be allowed to modify the > file while the server is running- if a change needs to be made while the > server is running, then it should be done through a call to ALTER SYSTEM. > > > > There’s no shortage of tools that, particularly with the merger in of > recovery.conf, want to modify and manipulate the file when the server is > down though. > > > > All that said, whatever code it is that we write for pg_basebackup to do > this properly should go into our client side library, so other tools can > leverage that and avoid having to write it themselves. > > > > Fair enough. In that case, don't we need some mechanism to ensure > that if the API fails, then the old contents are retained? Alter > system ensures that by writing first the contents to a temporary file, > but I am not sure if whatever is done by pg_basebackup has that > guarantee. I’m not sure that’s really the same. Certainly, pg_basebackup needs to deal with a partial write, or failure of any kind, in a clean way that indicates the backup isn’t good. The important bit is that the resulting file be one that ALTER SYSTEM and potentially other tools will be able to work with. Thanks, Stephen >
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