Stephen Frost <sfrost@snowman.net> writes:
> On Fri, Aug 2, 2019 at 18:27 Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The proposal seems to be to run through the .auto.conf file, remove any
>>> duplicates, and append the new entry at the end. That seems reasonable.
>> +1
> I disagree that this should only be addressed in alter system, as I’ve said
> before and as others have agreed with. Having one set of code that can be
> used to update parameters in the auto.conf and then have that be used by
> pg_basebackup, alter system, and external tools, is the right approach.
I don't find that to be necessary or even desirable. Many (most?) of the
situations where this would be important wouldn't have access to a running
backend, and maybe not to any PG code at all --- what if your tool isn't
written in C?
What if you want to access PG and your tool isn’t written in C? You use a module, extension, package, whatever, that provides the glue between what your language wants and what the C library provides. There’s psycopg2 for python, DBD::Pg for Perl, et al, and they use libpq. There’s languages that like to write their own too, like the JDBC driver, the Golang driver, but that doesn’t mean we shouldn’t provide libpq or that non-C tools can’t leverage libpq. This argument is just not sensible.
I agree entirely that we want to be able to modify auto.conf without having PG running (and without using single mode, bleh, that’s horrid..). I think we can accept that there we can’t necessarily *validate* that every option is acceptable but that’s not the same as being able to simply parse the file and modify a value.
I think it's perfectly fine to say that external tools need only append
to the file, which will require no special tooling. But then we need
ALTER SYSTEM to be willing to clean out duplicates, if only so you don't
run out of disk space after awhile.
Uh, if you don’t ever run ALTER SYSTEM then you could also “run out of disk space” due to external tools modifying by just adding to the file.
Personally, I don’t buy the “run out of disk space” argument but if we are going to go there then we should apply it appropriately.
Having the history of changes to auto.conf would actually be quite useful, imv, and worth a bit of disk space (heck, it’s not exactly uncommon for people to keep their config files in git repos..). I’d suggest we also include the date/time of when the modification was made.
Thanks,
Stephen