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
