Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

 > In particular, in order to consider it unexpected, you have to suppose
 >> that the content rules for postgresql.auto.conf are different from those
 >> for postgresql.conf (wherein we clearly allow last-one-wins).  Can you
 >> point to any user-facing documentation that says that?
 >
 > The backend and frontend tools don't modify postgresql.conf, and we
 > don't document how to modify postgresql.auto.conf at *all*, even though
 > we clearly now expect tool authors to go modifying it so that they can
 > provide the same capabilities that pg_basebackup does and which they
 > used to through recovery.conf, so I don't really see that as being
 > comparable.
 >
 > The only thing we used to have to go on was what ALTER SYSTEM did, and
 > then pg_basebackup went and did something different, and enough so that
 > they ended up conflicting with each other, leading to this discussion.

Or looking at it from another perspective - previously there was no
particular use-case for appending to .auto.conf, until it (implicitly)
became the only way of doing what recovery.conf used to do, and happened to
expose the issue at hand.

Leaving aside pg_basebackup and the whole issue of writing replication
configuration, .auto.conf remains a text file which could potentially
include duplicate entries, no matter how much we stipulate it shouldn't.
As-is, ALTER SYSTEM fails to deal with this case, which in my opinion
is a bug and a potential footgun which needs fixing.

(Though we'll still need to define/provide a way of writing configuration
while the server is not running, which will be guaranteed to be read in last
when it starts up).


Regards

Ian Barwick

--
  Ian Barwick                   https://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services