Re: unite recovery.conf and postgresql.conf

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: unite recovery.conf and postgresql.conf
Дата
Msg-id CA+U5nMLs-UWiydZ-jpOBj=-YDig36hp7rk__2Fj_RhuwLpp+XA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: unite recovery.conf and postgresql.conf  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: unite recovery.conf and postgresql.conf  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

>> In 9.2 the presence of recovery.conf can and therefore should continue
>> to act as it does in 9.1.
>
> This means that recovery.conf is renamed to recovery.done at the end of
> recovery. IOW, all settings in recovery.conf are reset when recovery ends.
> Then if you run "pg_ctl reload" after recovery, you'll get something like
> the following error message and the reload will always fail;
>
>   LOG:  parameter "standby_mode" cannot be changed without restarting
> the server

> To resolve this issue,

This issue exists whether or not we have recovery.conf etc., so yes,
we must solve the problem.


> I think that we need to introduce new GUC flag
> indicating parameters are used only during recovery, and need to define
> recovery parameters with that flag. Whenever "pg_ctl reload" is executed,
> all the processes check whether recovery is in progress, and ignore
> silently the parameters with that flag if not. I'm not sure how easy we
> can implement this. In addition to introducing that flag, we might need to
> change some processes which cannot access to the shared memory so that
> they can. Otherwise, they cannot know whether recovery is in progress.
> Or we might need to change them so that they always ignore recovery
> parameters.

The postmaster knows whether its in recovery or not without checking
shared memory. Various postmaster states describe this. If not
postmaster, other backends can run recoveryinprogress() as normal.

It makes sense to have a new flag and that is easily created and used.


> Another simple but somewhat restricted approach is to read and set
> all parameters specified in recovery.conf by using PGC_S_OVERRIDE.
> If we do this, those parameters cannot be changed after startup
> even if recovery.conf is renamed. But the problem is that a user also
> cannot change their settings by reloading the configuration files. This is
> obviously a restriction. But it doesn't break any backward compatibility,
> I believe. No? If a user prefers new functionality (i.e., reload recovery
> parameters) rather than the backward compatibility, he/she can specify
> parameters in postgresql.conf. Thought?

No need to create problems.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Shigeru Hanada
Дата:
Сообщение: Re: pgsql_fdw, FDW for PostgreSQL server
Следующее
От: Marcin Mańk
Дата:
Сообщение: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?