Re: pg_basebackup -R

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

In response to

Responses

Browse pgsql-hackers by date

  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