Re: Fast default stuff versus pg_upgrade

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fast default stuff versus pg_upgrade
Date: 2018-06-21 18:51:13
Message-ID: c7af2c37-67b1-7512-4630-71fe1db1d771@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/21/2018 01:53 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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

Attachment Content-Type Size
fix-default-8.patch text/x-patch 11.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-21 20:00:49 PSA: --enable-coverage interferes with parallel query scheduling
Previous Message Sergei Kornilov 2018-06-21 18:48:07 Re: Continue work on changes to recovery.conf API