Josh Berkus <josh@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
