Re: Fast default stuff versus pg_upgrade

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Fast default stuff versus pg_upgrade
Дата
Msg-id c7af2c37-67b1-7512-4630-71fe1db1d771@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Fast default stuff versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fast default stuff versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Fast default stuff versus pg_upgrade  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers

On 06/21/2018 01:53 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 06/21/2018 01:44 PM, Tom Lane wrote:
>>> So I'm thinking that the attidentity code is just wrong, and you should
>>> change that too while you're at it.
>> That should be backpatched if changed, no? I don't think we'd want this
>> to get out of sync between the branches. It would make later
>> backpatching more difficult for one thing.
> If you feel like it.  But if there's attmissingval code right next to it
> as of v11, then backpatches wouldn't apply cleanly anyway due to lack of
> context match, so I doubt there's really much gain to be had.
>
>             



I left that for a separate exercise. I think this does things the way 
you want. I must admit to being a bit surprised, I was expecting you to 
have more to say about the upgrade function than the pg_dump changes :-)

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re: Continue work on changes to recovery.conf API
Следующее
От: Tom Lane
Дата:
Сообщение: PSA: --enable-coverage interferes with parallel query scheduling