Re: pg_basebackup -R

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup -R
Date: 2017-02-09 11:17:00
Message-ID: CAA4eK1L5qDJJa1DyYWCfCGub6ebAhkh52mUS59XyLZLN2u=a2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 8, 2017 at 11:38 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I just tried out pg_basebackup -R and got the following recovery.conf file:
>
> standby_mode = 'on'
> primary_conninfo = 'user=rhaas passfile=''/home/rhaas/.pgpass''
> port=5432 sslmode=disable sslcompression=1 target_session_attrs=any'
>
> This seems fairly random to me. pg_basebackup explains:
>
> * Do not emit this setting if: - the setting is "replication",
> * "dbname" or "fallback_application_name", since these would be
> * overridden by the libpqwalreceiver module anyway. -
> not set or
> * empty.
>
> ...which looks like it got clubbed by pgindent, but anyway I'm not
> sure that's the best algorithm. passfile and target_session_attrs are
> both new in v10 and have non-empty default values, yet neither of them
> seems like something that you necessarily want in your
> automatically-created recovery.conf file. It seems like it would be
> more correct to leave out parameters that are set to the default
> value, rather than those that are set to an empty value.
>

+1. Sounds sensible thing to do.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stas Kelvich 2017-02-09 13:23:11 Re: logical decoding of two-phase transactions
Previous Message Thomas Munro 2017-02-09 11:01:25 Latch reset ordering bug in condition_variable.c