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

Greetings,

On Fri, Aug 2, 2019 at 18:47 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > On Fri, Aug 2, 2019 at 18:27 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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