Fujii Masao <masao.fujii@gmail.com> writes:
> We have three choices. Which do you like the best?
I'm in favor of defining a separate, content-free trigger file to enable
archive recovery. Not sure about the name "recovery.ready", though ---
that makes it look like one of the WAL archive transfer trigger files,
which does not seem like a great analogy. The pg_standby documentation
suggests names like "foo.trigger" for failover triggers, which is a bit
better analogy because something external to the database creates the
file. What about "recovery.trigger"?
As far as the other issues go, I think there is actually a prerequisite
discussion to be had here, which is whether we are turning the recovery
parameters into plain old GUCs or not. If they are plain old GUCs, then
they will presumably still have their values when we are *not* doing
recovery. That leads to a couple of questions:
* will seeing these values present in pg_settings confuse anybody?
* can the values be changed when not in recovery, if so what happens, and again will that confuse anybody?
* is there any security hazard from ordinary users being able to see what settings had been used?
If these settings are to be plain old GUCs, then I think we should just
stick them in postgresql.conf and forget about recovery.conf (although
of course someone could "include recovery.conf" if he were bent on
storing them separately). On the other hand, if we think they are *not*
plain old GUCs, maybe they shouldn't be in postgresql.conf. But the
source file isn't the first thing to worry about in that case.
regards, tom lane
