> 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
