> 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"?
Do we want a trigger file to enable recovery, or one to *disable* recovery? Or both? Also, I might point out that we're really confusing our users by talking about "recovery" all the time, if they're just using streaming replication. Just sayin' > * will seeing these values present in pg_settings confuse anybody? No. pg_settings already has a couple dozen "developer" parameters which nobody not on this mailing list understands. Adding the recovery parameters to it wouldn't confuse anyone further, and would have the advantage of making the recovery parameters available by monitoring query on a hot standby. For that matter, I'd suggest that we add a read-only setting called in_recovery. > * can the values be changed when not in recovery, if so what happens, > and again will that confuse anybody? Yes, and no. > * is there any security hazard from ordinary users being able to see > what settings had been used? primary_conninfo could be a problem, since it's possible to set a password there. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
