Re: pg_upgrade failure on Windows Server
От | Michael Paquier |
---|---|
Тема | Re: pg_upgrade failure on Windows Server |
Дата | |
Msg-id | CAB7nPqTJCiNXiMQODXjGeCG03767+Aaf3kjPFKi56TOZ6DXLkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade failure on Windows Server (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade failure on Windows Server
|
Список | pgsql-bugs |
On Thu, Mar 12, 2015 at 11:45 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Michael Paquier wrote: >> On Thu, Mar 12, 2015 at 6:50 AM, Alvaro Herrera >> <alvherre@2ndquadrant.com> wrote: > >> > Is this a backpatchable bug fix, or are we considering this only for the >> > master branch? >> >> It would be good to get that backpatched, that's something we really >> miss now IMO. Now it modifies libpgcommon, so Windows packagers (me >> being one) will certainly need to patch a bit stuff but that's a >> one-line changer so it's not a big deal. And I imagine that this is >> actually the reason why Asif reported that as a bug as well. > > I think it'd be better to patch only pg_upgrade in back branches, so > that there are no libpgcommon changes. Seems that would make life > easier for packagers (See the \connect thread, where Robert opined that > it'd be better to duplicate some routines in back branches rather than > refactor libpq code and move the common code to pgcommon. I didn't > completely agree with him at the time, but now that you mention > packagers pain, maybe he has a point.) > > So let's do the refactoring in the master branch only, and duplicate > the code in back branches. Nasty, but it seems the more robust > approach. This plan sounds fine to me. -- Michael
В списке pgsql-bugs по дате отправления: