All, First, if we're going to change behavior, I assert that we should stop calling stuff "recovery" and either call it "replica" or "standby". Our use of the word "recovery" confuses users; it is historical in nature and requires an understanding of PostgreSQL internals to know why it's called that. It's also inconsistent with our use of the word "standby" everywhere else.
Second, I haven't seen a response to this: > Do we want a trigger file to enable recovery, or one to *disable* recovery? Or both? I'll go further and say that we only want one trigger file by default, one which either enables or disables recovery. I'll further suggest that we: a) have a standby.on file which puts the server in replica/recovery mode if it's detected on startup, and b) that we poll for the standby.on file going away as a trigger to stop recovery and bring up the server in master mode, and c) that pg_basebackup automatically create a standby.on file. > Perhaps we need a new SCOPE attribute on pg_settings to show whether > the parameter applies in recovery, in normal or both. An overhaul of the category tree would also do that. I've been putting off an overhaul/cleanup of categories for pg_settings, maybe it's about time. > There is a potential security hole if people hardcode passwords into > primary_conninfo. As long as we document not to do that, we're OK. Yeah, I'd almost be inclined to actively prohibit this, but that would draw user complaints. We'll have to be satisfied with a doc plus a comment. Speaking of which, .pgpass could be better documented as an option for handling this sort of thing. Will take a stab, eventually. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
