Re: recovery_connections cannot start (was Re: master in standby mode croaks)

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Дата
Msg-id 4BD1C1C50200002500030D6A@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> wrote:
> On Fri, 2010-04-23 at 23:10 +0300, Heikki Linnakangas wrote:
>> So my proposal would be:
>> 
>> wal_mode=crash/archive/standby
> I definitely don't like the word "crash", which may scare and
> confuse people. I don't think I would ever set any parameter to a
> word like "crash" since it isn't clear whether it allows that
> event or protects against it. Also, I don't like the word
> "standby" on its own, since that has already been used for Warm
> Standby for some time, which corresponds to the "archive" setting
> and is therefore confusing.
Good points, although "recovery" instead of "crash" would seem to
cover that.
> How about something like
> 
> wal_additional_info = none | archive | connect
> 
> Then its easy to understand that things slow down when you request
> additional information in the WAL, and also clear that Hot Standby
> requires slightly more info on top of that. It's also clear that
> this has nothing at all to do with the delivery mechanism.
Are we going to support running warm standby through SR?  If so,
"connect" seems confusing for the level to support hot standby. 
Perhaps "live"?:
wal_mode=recovery/archive/live
-Kevin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Следующее
От: Tom Lane
Дата:
Сообщение: Re: recovery_connections cannot start (was Re: master in standby mode croaks)