Re: [HACKERS] pg_basebackup -R - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] pg_basebackup -R
Date
Msg-id CA+Tgmoa87xg5_ZWsQXeUhijC-h0b8bL6beG4i6AjKkUk-ETZ+Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_basebackup -R  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] pg_basebackup -R  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Tue, Feb 14, 2017 at 11:36 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> In short, I'd like to think that we should just filter out those two
>>> parameters by name and call it a day. Or introduce an idea of value
>>> set for the environment by adding some kind of tracking flag in
>>> PQconninfoOption? Though I am not sure that it is worth complicating
>>> libpq to just generate recovery.conf in pg_basebackup.
>>
>> Yeah, I'm not sure what the best solution is.  I just thought it was strange.
>
> Thinking more about this, perhaps the correct answer is to do nothing?
> target_session_attrs being set is rather similar to sslmode or
> sslcompression for example. They are here but don't hurt. The same
> thing applies to passfile: if the file is not here the client would
> still ask for input. If it is here, things are helped a bit.

Let's wait and see if anybody else has an opinion.  I imagine that, as
further libpq parameters are added, eventually this is going to get
long and annoying enough that we want to do something about it.  But
we might not have reached that point just yet.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Add checklist item for psql completion to commitfest review
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Add doc advice about systemd RemoveIPC