Re: unite recovery.conf and postgresql.conf

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: unite recovery.conf and postgresql.conf
Дата
Msg-id CA+TgmoYkqFDAE219UXzQv=5Z6MvgkaxOTsA0Lz2JeAohoDojZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: unite recovery.conf and postgresql.conf  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Wed, Dec 14, 2011 at 8:56 PM, Josh Berkus <josh@agliodbs.com> wrote:
> So for streaming replication, will I need to have a standby.enabled
> file, or will there be a parameter in postgresql.conf (or included
> files) which controls whether or not that server is a standby, available?
>
> In the best of all possible worlds, I'd really like to have a GUC which
> 100% controls whether or not the current server is a standby.

I think that would be a bad idea, because then how would pg_ctl
promote work?  It'd have to permanently change the value of that GUC,
which means rewriting a postgresql.conf file with an arbitrary forest
of comments and include files, and we can't do that now or, probably,
ever.  At least not reliably enough for this kind of use case.  I
think what Greg is going for is this:

1. Get rid of recovery.conf - error out if it is seen
2. For each parameter that was previously a recovery.conf parameter,
make it a GUC
3. For the parameter that was "does recovery.conf exist?", replace it
with "does standby.enabled exist?".

IMHO, as Greg says, that's as much change as we can cope with in one release.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Command Triggers
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Race condition in HEAD, possibly due to PGPROC splitup