From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup -R |
Date: | 2017-02-10 02:40:05 |
Message-ID: | CAB7nPqS+BSYe5y1khfJZU4sGZ84+SjKJWJgioE+ReV5xpfeAiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-02-10 04:52:17 | Re: Provide list of subscriptions and publications in psql's completion |
Previous Message | Stephen Frost | 2017-02-10 01:54:42 | Removal of deprecated views pg_user, pg_group, pg_shadow |