Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers