On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus <j...@agliodbs.com> wrote:
> Jaime,
>> well, after upgrade you should do checks. and even if it happens,
>> after it happens once people will be aware of the change.
>> now, some suggestions were made to avoid the problem. 1) read the file
>> if exists last in the process of postgresql.conf, 2) add a GUC
>> indicating if it should read it and include it (not using it as a
>> trigger file). another one, 3) include in this release an
>> include_if_exists directive and give a warning if it sees the file
>> then include it, on next release remove the include_if_exists (at
>> least that way people will be warned before breaking compatibility)
> I think all of these suggestions just make our code more complicated
> without improving the upgrade situation.

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?

> The reason given (and I think it's pretty good) for erroring on
> recovery.conf is that we don't want people to accidentally take a server
> out of replication because they didn't check which version of PostgreSQL
> they are on.

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 ;)

Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitaciĆ³n
Phone: +593 4 5107566         Cell: +593 987171157

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to