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