From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: pgsql: Support arrays over domains.
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-committers@postgresql.org
References: <E1dyLlE-0002gT-H5@gemulon.postgresql.org>
 <678e49f8-e32a-9b96-8e3f-a8c63d2f0e18@2ndQuadrant.com>
 <24123.1506799963@sss.pgh.pa.us>
Message-ID: <664a27a2-a186-addc-5102-d52109496340@2ndQuadrant.com>
Date: Sat, 30 Sep 2017 15:37:20 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <24123.1506799963@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-MW
Precedence: bulk
Sender: pgsql-committers-owner@postgresql.org


On 09/30/2017 03:32 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> We seem to have caused a problem with pg_upgrade :-(
>>     pg_restore: [archiver (db)] could not execute query: ERROR:  pg_type
>>     array OID value not set when in binary upgrade mode
>> Here we're upgrading from 9.2 to HEAD. Of course, there isn't an array
>> oid for the domain in 9.2.
> Hmm.  That's pretty annoying.  We could certainly go ahead and assign
> some unused type OID to the new array type, but the receiving backend
> can't really do that, since it doesn't know which type OIDs will be
> assigned later in the dump file.
>
> Maybe we could put the burden on pg_upgrade (pg_dump --binary-upgrade)
> to select an OID that's not in use in the source database.
>
> 			


Yes, I think we'll have to do something like that.

cheers

andrew

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


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers