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>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fast default stuff versus pg_upgrade
Date: 2018-06-21 17:02:55
Message-ID: 3db3a1e3-e415-8fe2-954a-4ab16bb404b2@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/21/2018 12:39 PM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On June 21, 2018 9:04:28 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This isn't really ready to go. One clear problem is that you broke
>>> pg_dump'ing from any pre-v11 version, because you did not add suitable
>>> null outputs to the pre-v11 query variants in getTableAttrs.
>> Thought the same for a bit - think it's OK though, because there a check for PQfnumber being bigger than 0...
> It won't actually crash, but it will spit out lots of ugly warnings.
>
>

I followed the pattern used for attidentity. But why will it spit out
warnings? It doesn't ask for the missing stuff from an older version.

Incidentally, I just checked this by applying the patch and then running
through the buildfarm's cross version upgrade check. All was kosher.
Upgrade from all live branches to the patched master went without a hitch.

cheers

andrew

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-21 17:08:45 Re: Wrong cost estimation for foreign tables join with use_remote_estimate disabled
Previous Message Tomas Vondra 2018-06-21 16:57:25 Re: WAL prefetch