Re: v12 pg_basebackup fails against older servers (take two) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: v12 pg_basebackup fails against older servers (take two)
Date
Msg-id 20191023063720.GE3286@paquier.xyz
Whole thread Raw
In response to Re: v12 pg_basebackup fails against older servers (take two)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: v12 pg_basebackup fails against older servers (take two)
List pgsql-hackers
On Tue, Oct 22, 2019 at 09:53:45AM -0400, Stephen Frost wrote:
> Yeah..  Something along those lines definitely seems like it'd be better
> as that would force anyone adding new options to explicitly say which
> server version the option makes sense for.  Would it make sense to have a
> minimum and a maximum (and a "currently live" or some such indicator, so
> we aren't changing the max every release)?

Yeah.  A maximum may help to handle properly the cycling of deprecated
options in connstrs, so I see your point.  Not sure that this
"currently-live" indicator is something to care about if we know
already the range of versions supported by a parameter and the
version of the backend for a live connection.  My take is that it
would be more consistent to have a PG_MAJORVERSION_NUM for this
purpose in pg_config.h as well (I honestly don't like much the
existing tweaks for the major version numbers like "PG_VERSION_NUM /
100" in pg_basebackup.c & co for example).  If we were to have a
maximum, couldn't there also be issues when it comes to link a binary
with a version of libpq which has been compiled with a version of
Postgres older than the version of the binary?  For example, imagine a
version of libpq compiled with v11, used to link to a pg_basebackup
from v12..  (@_@)

> The other thought I had was if we should, perhaps, be skipping settings
> whose values haven't been changed from the default value.  Currently, we
> end up with a bunch of stuff that, in my experience anyway, just ends up
> being confusing to people, without any particular benefit, like
> 'sslcompression=0' when SSL wasn't used, or 'krbsrvname=postgres' when
> Kerberos/GSSAPI wasn't used...

Couldn't this become a problem if we were to change the default for
some parameters?  There has been a lot of talks for example about how
bad sslmode's default it for one, even if nobody has actually pulled
the trigger to change it.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: configure fails for perl check on CentOS8
Next
From: "李杰(慎追)"
Date:
Subject: 回复:回复:Bug about drop index concurrently