Re: unite recovery.conf and postgresql.conf
Peter Eisentraut <peter_e@gmx.net>
From: Peter Eisentraut <peter_e@gmx.net>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-09-15T10:58:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restructure error handling in reading of postgresql.conf.
- d56b3afc0376 9.2.0 cited
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.