Re: Turning recovery.conf into GUCs
От | Jaime Casanova |
---|---|
Тема | Re: Turning recovery.conf into GUCs |
Дата | |
Msg-id | CAJKUy5g=ObyfC-7X7X-Mk76kW5g4rCxWnA1505FEv9GG5SM2AQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Turning recovery.conf into GUCs (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus <josh@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
В списке pgsql-hackers по дате отправления: