On 10/18/2013 02:58 PM, Jaime Casanova wrote:
> well #3 just add a line in postgresql.conf (an include_if_exists) and
> current patch gives an error in case it finds the file (i'm suggesting
> to make it a warning instead).
> how does that makes our code more complicated?
Well, that's a couple extra lines only, I know. However, it doesn't
actually help with the breakage any, since recovery.conf *still* won't
work as a trigger file.
The only thing which would prevent breakage (proposed by Simon, I think)
is having recovery.conf have an include_if_exists, AND have
recovery.conf be an 'alternate' name for replication.trigger. However,
even this would break, and in IMHO ways which would tend to happen at
failover time rather than upgrade time.
To put it clearly: if we're going to have breakage, I want it to be at
upgrade time, when the database is *already down*, and not at failover
time or some other time when downtime is not planned.
> well, people will go out of replication also if they forgot the
> recovery trigger file
> even if they set the variables in postgresql.conf
>
> it happens two me twice today ;)
Right. What I'd like to avoid is having folks try to use, for example,
repmgr 1.2 with PostgreSQL 9.4 and have their replication break and them
not notice for a couple hours of operation. I'd rather have PostgreSQL
9.4 refuse to come up, so that they know *immediately* that something is
wrong.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
