Re: unite recovery.conf and postgresql.conf

On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This seems like it's already predetermining the outcome of the argument
> about recovery.conf.  Mind you, I'm not unhappy with this choice, but
> it's hardly implementing only behavior that's not being debated.
>
> If we're satisfied with not treating recovery-only parameters different
> from run-of-the-mill GUCs, this is fine.

Okay, we need to reach a consensus about the treatment of
recovery.conf.

We have three choices. Which do you like the best?

#1
Use empty recovery.ready file to enter arhicve recovery. recovery.conf
is not read automatically. All recovery parameters are expected to be
specified in postgresql.conf. If you must specify them in recovery.conf,
you need to add "include 'recovery.conf'" into postgresql.conf. But note
that that recovery.conf will not be renamed to recovery.done at the
end of recovery. This is what the patch I've posted does. This is
simplest approach, but might confuse people who use the tools which
depend on recovery.conf.

#2
Use empty recovery.ready file to enter archive recovery. recovery.conf
is read automatically. You can specify recovery parameters in
recovery.conf without adding "include 'recovery.conf'" into
postgresql.conf.  But note that that recovery.conf will not be renamed
to recovery.done at the end of recovery. If we adopt this, we might
need to implement what Dimitri suggested. I guess this is not so difficult
thing.
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00745.php

#3
Use recovery.conf file to enter archive recovery. recovery.conf is read
automatically, and will be renamed to recovery.done at the end of
recovery. This is least confusing approach for the existing users, but
I guess we need to add lots of code (e.g., as Peter suggested, we might
need to invent new context setting like PGC_RECOVERY) to address
the problem I pointed before.
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00482.php


If we want to use recovery.conf as a temporary configuration file for
recovery (i.e., configuration file disappears after use), we must choose
#3. If we can live with that recovery.conf is treated as a permanent
configuration file but don't want to add "include 'recovery.conf'" into
postgresql.conf, #2 is best. If we don't use recovery.conf or mind
editing postgresql.conf to use recovery.conf, #1 is best. Which behavior
are you expecting?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center