Re: pg_upgrade failure on Windows Server
От | Asif Naeem |
---|---|
Тема | Re: pg_upgrade failure on Windows Server |
Дата | |
Msg-id | CAEB4t-PWLjBvs8Qi8dnBFDJKZs6=Q9oLLFTL7XoHURJA4DYkOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade failure on Windows Server (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: pg_upgrade failure on Windows Server
|
Список | pgsql-bugs |
+1 On Fri, Mar 13, 2015 at 4:32 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > 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 по дате отправления: