On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
