Re: unite recovery.conf and postgresql.conf
От | Bruce Momjian |
---|---|
Тема | Re: unite recovery.conf and postgresql.conf |
Дата | |
Msg-id | 201110111429.p9BETp212229@momjian.us обсуждение исходный текст |
Ответ на | Re: unite recovery.conf and postgresql.conf (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: unite recovery.conf and postgresql.conf
|
Список | pgsql-hackers |
Fujii Masao wrote: > On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus <josh@agliodbs.com> wrote: > > > >>> Tatsuo/Josh/Robert also discussed how recovery.conf can be used to > >>> provide parameters solely for recovery. That is difficult to do > >>> without causing all downstream tools to make major changes in the ways > >>> they supply parameters. > >> > >> Actually, this case is easily solved by an "include recovery.conf" > >> parameter. ?So it's a non-issue. > > > > That is what I've suggested and yes, doing that is straightforward. > > Even if we do that, you still need to modify the tool so that it can handle > the recovery trigger file. recovery.conf is used as just a configuration file > (not recovery trigger file at all). It's not renamed to recovery.done at the > end of recovery. If the tool depends on the renaming from recovery.conf > to recovery.done, it also would need to be modified. If the tool needs to > be changed anyway, why do you hesitate in changing it so that it adds > "include recovery.conf" into postgresql.conf automatically? > > Or you think that, to keep the backward compatibility completely, > recovery.conf should be used as not only a configuration file but also a > recovery trigger one and it should be renamed to recovery.done at > the end of recovery? As much as I appreciate Simon's work in this area, I think we are still unclear if keeping backward-compatibility is worth the complexity required for future users. Historically we have been bold in changing postgresql.conf settings to improve clarity, and that approach has served us well. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: