Re: unite recovery.conf and postgresql.conf

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