Re: Fast default stuff versus pg_upgrade - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Fast default stuff versus pg_upgrade
Date
Msg-id 3db3a1e3-e415-8fe2-954a-4ab16bb404b2@2ndQuadrant.com
Whole thread Raw
In response to Re: Fast default stuff versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fast default stuff versus pg_upgrade
List pgsql-hackers

On 06/21/2018 12:39 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On June 21, 2018 9:04:28 AM PDT, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WAL prefetch
Next
From: Tom Lane
Date:
Subject: Re: Wrong cost estimation for foreign tables join with use_remote_estimate disabled