Re: unite recovery.conf and postgresql.conf

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unite recovery.conf and postgresql.conf
Date: 2011-09-15 10:58:21
Message-ID: 1316084301.25115.8.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-09-15 11:04:43 Re: unite recovery.conf and postgresql.conf
Previous Message Fujii Masao 2011-09-15 08:52:53 Re: [REVIEW] pg_last_xact_insert_timestamp