Re: v12 pg_basebackup fails against older servers (take two)

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Devrim Gündüz <devrim(at)gunduz(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: v12 pg_basebackup fails against older servers (take two)
Date: 2019-10-22 13:53:45
Message-ID: 20191022135345.GZ6962@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> On Tue, Oct 22, 2019 at 09:06:03AM -0400, Stephen Frost wrote:
> > Here's just a quick rough-up of a patch (it compiles, I haven't tried it
> > out more than that) that adds in a check to skip gssencmode on older
> > versions. If it seems like a reasonable approach then I can test it out
> > and deal with back-patching it and such.
>
> Here is a thought. We could tackle the problem at its source and
> track in internalPQconninfoOption the minimum version supported by a
> parameter. This way, we could make sure that libpq routines similar
> to PQconninfo() never return an option which is not compatible with a
> a live connection, and we won't forget that if the problem shows up
> again because creating a new parameter would require to add a new
> version number. There is an advantage here: internalPQconninfoOption
> is an internal structure, so this should be back-patchable.

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 sene to have a
minimum and a maximum (and a "currently live" or some such indicator, so
we aren't changing the max every release)?

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...

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-10-22 15:27:02 Re: pgbench - refactor init functions with buffers
Previous Message Michael Paquier 2019-10-22 13:35:50 Re: v12 pg_basebackup fails against older servers (take two)