Re: [HACKERS] pg_basebackup -R

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] pg_basebackup -R
Дата
Msg-id CAA4eK1L5qDJJa1DyYWCfCGub6ebAhkh52mUS59XyLZLN2u=a2w@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] pg_basebackup -R  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] pg_basebackup -R  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Feb 8, 2017 at 11:38 PM, Robert Haas <robertmhaas@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: [HACKERS] Latch reset ordering bug in condition_variable.c
Следующее
От: Stas Kelvich
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions