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

From Michael Paquier
Subject Re: [HACKERS] pg_basebackup -R
Date
Msg-id CAB7nPqS+BSYe5y1khfJZU4sGZ84+SjKJWJgioE+ReV5xpfeAiQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_basebackup -R  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] pg_basebackup -R  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> +1.  Sounds sensible thing to do.

Hm. It seems to me that PGPASSFILE still needs to be treated as an
exception because it is set to $HOME/.pgpass without any value set in
PQconninfoOption->compiled and it depends on the environment. Similar
rules apply to fallback_application_name, dbname and replication as
well, so they would need to be kept as checked on an individual basis.

Now it is true that pg_basebackup -R enforces the value set for a
parameter in the created string if its environment variable is set.
Bypassing those values would potentially break applications that rely
on the existing behavior.

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion