From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: pgsql: Update pg_upgrade test for reg* to include regrole and
 regnamesp
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-committers@lists.postgresql.org
References: <E1gRS1V-0007eS-1p@gemulon.postgresql.org>
 <8863.1543297423@sss.pgh.pa.us>
 <20181127063226.mpyijg3jwrmmm3rr@alap3.anarazel.de>
 <6f5edd28-e55f-7399-d89c-d2d1ed2d1e51@2ndQuadrant.com>
 <2735.1543333649@sss.pgh.pa.us>
 <20181127203806.behekoj55rnwuuvg@alap3.anarazel.de>
Message-ID: <533c4deb-91a9-0ad9-22a2-5c230bef28f8@2ndQuadrant.com>
Date: Tue, 27 Nov 2018 16:26:36 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181127203806.behekoj55rnwuuvg@alap3.anarazel.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-MW
Precedence: bulk


On 11/27/18 3:38 PM, Andres Freund wrote:
> Hi,
>
> On 2018-11-27 10:47:29 -0500, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> In any case, I think we will probably need to bite the bullet and have
>>> pg_dump render LOs in OID order.
>> +1.  Looking at the relevant code:
>>
>>      /*
>>       * Currently, we re-fetch all BLOB OIDs using a cursor.  Consider scanning
>>       * the already-in-memory dumpable objects instead...
>>       */
>>      if (fout->remoteVersion >= 90000)
>>          blobQry = "DECLARE bloboid CURSOR FOR SELECT oid FROM pg_largeobject_metadata";
>>      else
>>          blobQry = "DECLARE bloboid CURSOR FOR SELECT DISTINCT loid FROM pg_largeobject";
> Done. Thanks for chiming in.
>
> Andrew, the <= 9.2 failure https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2018-11-27%2018%3A18%3A21
> seems to be related to nabstime etc not being available anymore.  We've
> not backpatched
>
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Branch: REL_11_STABLE Release: REL_11_0 [184951a48] 2018-10-12 19:33:56 -0400
> Branch: REL_10_STABLE Release: REL_10_6 [9320263ae] 2018-10-12 19:33:56 -0400
> Branch: REL9_6_STABLE Release: REL9_6_11 [2ad422ce1] 2018-10-12 19:33:56 -0400
> Branch: REL9_5_STABLE Release: REL9_5_15 [43cc4e49e] 2018-10-12 19:33:56 -0400
> Branch: REL9_4_STABLE Release: REL9_4_20 [7b88c1ddd] 2018-10-12 19:33:57 -0400
> Branch: REL9_3_STABLE Release: REL9_3_25 [fb583c80d] 2018-10-12 19:33:57 -0400
>
>      Remove abstime, reltime, tinterval tables from old regression databases.
>
> that far.  I've locally verified that upgrade works after
>
> SELECT format('ALTER TABLE %s DROP COLUMN %s;', attrelid::regclass, attname) FROM pg_attribute WHERE attrelid > 16384 AND atttypid IN ('abstime'::regtype, 'reltime'::regtype, 'tinterval'::regtype)
> \gexec
>
> or something in that vein.
>

Thanks.


I'm just dropping the tables for REL_12. There is no point in just 
dropping the columns - they are one-column tables.


The reason you're seeing this is that given the discussion about 
pg_upgrade support I wanted to make sure that we had coverage for live + 
2 releases. Should be green the next time it reports.


cheers


andrew

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