Re: Feature Request: pg_replication_master()

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Feature Request: pg_replication_master()
Дата
Msg-id 50E5CF6A.2060403@agliodbs.com
обсуждение исходный текст
Ответ на Re: Feature Request: pg_replication_master()  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Feature Request: pg_replication_master()  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Robert,

> In my view, the biggest problem with recovery.conf is that the
> parameters in there are not GUCs, which means that all of the
> infrastructure that we've built for managing GUCs does not work with
> them.  As an example, when we converted recovery.conf to use the same
> lexer that the GUC machinery uses, it allowed recovery.conf values to
> be specified unquoted in the same circumstances where that was already
> possible for postgresql.conf.  But, you still can't use SHOW or
> pg_settings with recovery.conf parameters, and I think pg_ctl reload
> doesn't work either.  If we make these parameters into GUCs, then
> they'll work the same way everything else works.  Even if (as seems
> likely) we end up still needing a trigger file (or a special pg_ctl
> mode) to initiate recovery, I think that's probably a win.

I agree that it would be an improvement, and I would be happy just to
see the parameters become GUCs.

I'm just saying that I'll still be pushing to get rid of the requirement
for recovery.conf in 9.4, that's all.

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



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

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_upgrade test script creates port conflicts in parallel testing