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