On tor, 2011-09-15 at 16:54 +0900, Fujii Masao wrote: > On Wed, Sep 14, 2011 at 6:33 PM, Peter Eisentraut <pete...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
