From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 14:37:58 |
Message-ID: | 10986.1316097478@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> It seems to need a bit more time until we've reached a consensus about
> the treatment of recovery.conf. How about committing the core patch
> first, and addressing the recovery.conf issue as a different patch later?
> The attached patch provides a core part of the feature, i.e., it moves
> every recovery parameters from recovery.conf to postgresql.conf.
> Even if you create recovery.conf, the server doesn't read it automatically.
> The patch renames recovery.conf to recovery.ready, so if you want to
> enter archive recovery or standby mode, you need to create
> recovery.ready file in the cluster data directory. Since recovery.ready is
> just a signal file, its contents have no effect.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-09-15 14:44:43 | psql setenv command |
Previous Message | Fujii Masao | 2011-09-15 14:32:06 | Re: unite recovery.conf and postgresql.conf |