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:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to