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.