On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus <j...@agliodbs.com> wrote:
>>> Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
>>> provide parameters solely for recovery. That is difficult to do
>>> without causing all downstream tools to make major changes in the ways
>>> they supply parameters.
>> Actually, this case is easily solved by an "include recovery.conf"
>> parameter.  So it's a non-issue.
> That is what I've suggested and yes, doing that is straightforward.

Even if we do that, you still need to modify the tool so that it can handle
the recovery trigger file. recovery.conf is used as just a configuration file
(not recovery trigger file at all). It's not renamed to recovery.done at the
end of recovery. If the tool depends on the renaming from recovery.conf
to recovery.done, it also would need to be modified. If the tool needs to
be changed anyway, why do you hesitate in changing it so that it adds
"include recovery.conf" into postgresql.conf automatically?

Or you think that, to keep the backward compatibility completely,
recovery.conf should be used as not only a configuration file but also a
recovery trigger one and it should be renamed to recovery.done at
the end of recovery?


Fujii Masao
NTT Open Source Software Center

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to