Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Aug 5, 2019 at 2:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think Stephen is not being unreasonable to suggest that we need some >> documentation about what external tools may safely do to pg.auto.conf. >> So somebody's got to write that.
> I mean, really? We're going to document that if you want to add a > setting to the file, you can just append it, but that if you find > yourself desirous of appending so many settings that the entire disk > will fill up, you should maybe reconsider? Perhaps I'm being mean > here, but that seems like it's straight out of the > blinding-flashes-of-the-obvious department.
I don't think we need to go on about it at great length, but it seems to me that it'd be reasonable to point out that (a) you'd be well advised not to touch the file while the postmaster is up, and (b) last setting wins. Those things are equally true of postgresql.conf of course, but I don't recall whether they're already documented.
Folks certainly modify postgresql.conf while the postmaster is running pretty routinely, and we expect them to which is why we have a reload option, so I don’t think we can say that the auto.conf and postgresql.conf are to be handled in the same way.
Last setting wins, duplicates should be ignored and may be removed, comments should be ignored and may be removed, and appending to the file is acceptable for modifying a value. I’m not sure how much we really document the structure of the file itself offhand- back when users were editing it we could probably be a bit more fast and loose with it, but now that we have different parts of the system modifying it along with external tools doing so, we should probably write it down a bit more clearly/precisely.
I suspect the authors of pg_conftool would appreciate that too, so they could make sure that they aren’t doing anything unexpected or incorrect.