Re: Turning recovery.conf into GUCs

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Turning recovery.conf into GUCs
Дата
Msg-id 54738EEC.7020706@agliodbs.com
обсуждение исходный текст
Ответ на Re: Turning recovery.conf into GUCs  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Turning recovery.conf into GUCs  (Alex Shulgin <ash@commandprompt.com>)
Re: Turning recovery.conf into GUCs  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 11/24/2014 09:24 AM, Jaime Casanova wrote:
>> ... I don't honestly think we need a 4th method for promotion.
>>
> 
> this is not for promotion, this is to force postgres to start in
> recovery mode and read recovery configuration parameters.
> 
>> The main reason to want a "we're in recovery file" is for PITR rather
>> than for replication, where it has a number of advantages as a method,
>> the main one being that recovery.conf is unlikely to be overwritten by
>> the contents of the backup.
>>
> 
> only that you need to start in recovery mode to start replication

Right, but my point is that having a trigger file *is not necessary for
replication, only for PITR* -- and maybe not necessary even for PITR.
That is, in a streaming replication configuration, having a
"standby_mode = on|off" parameter is 100% sufficient to control
replication with the small detail that "pg_ctl promote" needs to set it
in pg.auto.conf or conf.d.

And, now, having given it some thought, I'm going to argue that it's not
required for PITR either, provided that we can use the auto.conf method.

Before I go into my ideas, though, what does the current patch do
regarding non-replication PITR?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: polymorphic types - enforce casting to most common type automatically
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs