Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fTYnM-00031G-Hr for pgsql-admin@arkaria.postgresql.org; Thu, 14 Jun 2018 20:24:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fTYnL-00063Q-0r for pgsql-admin@arkaria.postgresql.org; Thu, 14 Jun 2018 20:24:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fTYnK-00063H-Pm for pgsql-admin@lists.postgresql.org; Thu, 14 Jun 2018 20:24:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fTYnH-0007XU-Px for pgsql-admin@lists.postgresql.org; Thu, 14 Jun 2018 20:24:34 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w5EKOS4i010538; Thu, 14 Jun 2018 16:24:28 -0400 From: Tom Lane To: David Modica cc: "pgsql-admin@lists.postgresql.org" Subject: Re: binary upgade errors In-reply-to: <7cb957dd12774a52ac8a680b73910c5b@imaginesoftware.com> References: <7cb957dd12774a52ac8a680b73910c5b@imaginesoftware.com> Comments: In-reply-to David Modica message dated "Thu, 14 Jun 2018 15:51:20 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10536.1529007868.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jun 2018 16:24:28 -0400 Message-ID: <10537.1529007868@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Modica writes: > I have been unsuccessfully trying to use pg_upgrade to upgrade from 9.6 = to 10.4. > we have the uint extension in some of the databases. a combination of th= at extension > and probably how we have used it is causing the upgrade to fail. I will = include the error msg. > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 4538; 1247 280489 DOMAI= N bool_t postgres > pg_restore: [archiver (db)] could not execute query: ERROR: cannot cast= type integer to public.uint1 > Command was: > -- For binary upgrade, must preserve pg_type oid > SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('280489'::pg_catal= og.oid); > CREATE DOMAIN "its"."bool_t" AS "public"."uint1" DEFAULT (0)::"public"."= uint1"; Hmm ... it looks like this domain is depending on there to be a cast from integer to uint1, but that hasn't been created yet. There may be a bug here; I'm not sure why pg_dump didn't delay dumping the domain to after it'd dumped the cast. In the meantime, though, it seems like it would work (and probably be faster anyway) if you spelled the default value like '0'::uint1 rather than 0::uint1, as the former isn't depending on any run-time cast. So try altering the domain like that and then doing the upgrade. regards, tom lane