Re: unite recovery.conf and postgresql.conf
От | Peter Eisentraut |
---|---|
Тема | Re: unite recovery.conf and postgresql.conf |
Дата | |
Msg-id | 1316084301.25115.8.camel@fsopti579.F-Secure.com обсуждение исходный текст |
Ответ на | Re: unite recovery.conf and postgresql.conf (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: unite recovery.conf and postgresql.conf
|
Список | pgsql-hackers |
On tor, 2011-09-15 at 16:54 +0900, Fujii Masao wrote: > On Wed, Sep 14, 2011 at 6:33 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > > On tis, 2011-09-13 at 17:10 +0100, Simon Riggs wrote: > >> So treat postgresql.conf as if it has an automatic "include > >> recovery.conf" in it. The file format is the same. > > > > Sounds good. That would also have the merit that you could use, say, > > different memory settings during recovery. > > One problem of this is that recovery.conf is relative to the configuration > file directory instead of data directory if we treat it as an "include" file. Treat it *as if* it were an included file. A special included file if you will. > If we'd like to treat recovery.conf as if it's under the data directory, I'm > afraid that we should add complicated code to parse recovery.conf after > the value of data_directory has been determined from postgresql.conf. > Furthermore, what if recovery.conf has another setting of data_directory? Perhaps that could be addresses by inventing a new context setting PGC_RECOVERY so that you can only set sane values. > Since recovery.conf is a configuration file, it's intuitive for me to put it > in configuration file directory rather than data directory. So I'm not inclined > to treat recovery.conf as if it's under data directory. Is this OK? It's not a configuration file, because it disappears after use. (And a lot of configuration file management systems would be really upset if we had a configuration file that behaved that way.) The whole point of this exercise is allowing the permanent configuration file parameters to be moved to a real configuration file (postgresql.conf), while leaving the temporary settings separately. Alternatively, we could just forget about the whole thing and move everything to postgresql.conf and treat recovery.conf as a simple empty signal file. I don't know if that's necessarily better.
В списке pgsql-hackers по дате отправления: