On Sat, Sep 17, 2011 at 4:22 AM, Joshua Berkus <j...@agliodbs.com> wrote: >> 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"?
I'm OK with that name. > Do we want a trigger file to enable recovery, or one to *disable* recovery? > Or both? ISTM that only supporting a trigger file to enable recovery is less confusing. >> * 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. +1 >> * 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. True. I agree that primary_conninfo should be restricted to superuser. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
