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  (Asif Naeem <anaeem.it@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #12859: views much slower in 9.4.1 than 8.4.7
Следующее
От: jaime soler
Дата:
Сообщение: Re: BUG #12854: PG Admin 3 Restore/Import Button