> 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