Josh Berkus <j...@agliodbs.com> writes: > 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.
Are we all talking about the same thing? In my mind recovery.conf is for configuring a point-in-time archive recovery run. It's got nothing to do with either replication or standbys. Perhaps part of our problem here is overloading that case with standby behavior. > 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? As far as the PITR scenario is concerned, only the former can possibly make any sense; the latter would be downright dangerous. >> 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. I think that marking the GUC as "only readable by superuser" is a sufficient fix. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers