Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Zj9Eg-0004XI-6w for pgsql-admin@arkaria.postgresql.org; Mon, 05 Oct 2015 17:07:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1Zj9Ef-0005FX-PK for pgsql-admin@arkaria.postgresql.org; Mon, 05 Oct 2015 17:07:37 +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.84) (envelope-from ) id 1Zj9D0-0003CY-Ry for pgsql-admin@postgresql.org; Mon, 05 Oct 2015 17:05:54 +0000 Received: from smtp2.cvent.com ([192.190.92.246]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zj9Cx-00069t-36 for pgsql-admin@postgresql.org; Mon, 05 Oct 2015 17:05:53 +0000 X-IronPort-AV: E=Sophos;i="5.17,639,1437451200"; d="scan'208,217";a="7931306" From: "Guo, Yun" To: "pgsql-admin@postgresql.org" Subject: Re: pg_upgrade from 9.3 to 9.4 fails Thread-Topic: pg_upgrade from 9.3 to 9.4 fails Thread-Index: AQHQ/4mcAUs7p8odSEODO5MGegI4x55dIRKA Date: Mon, 5 Oct 2015 17:05:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 Content-Type: multipart/alternative; boundary="_000_D2381B7B48445yguocventcom_" MIME-Version: 1.0 X-Pg-Spam-Score: -1.5 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --_000_D2381B7B48445yguocventcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Yun > Date: Monday, October 5, 2015 at 12:19 PM To: "pgsql-admin-owner@postgresql.org" > Subject: pg_upgrade from 9.3 to 9.4 fails Hi, I=92m trying to use pg_upgrade to upgrade 9.3 to 9.4. And I observed weird = behavior, that if I have the old 9.3 server up and running the check would = pass, but if I shut it down it would fail. Any idea why would it behave th= is way? Is there a workaround for this issue? With old 9.3 running: -bash-4.1$ ps -ef | grep pg.old postgres 16243 1 0 16:12 pts/0 00:00:00 /usr/pgsql-9.3/bin/postgres= -D /data/pg.old postgres 16261 15160 0 16:13 pts/0 00:00:00 grep pg.old -bash-4.1$ pg_upgrade -b /usr/pgsql-9.3/bin -B /usr/pgsql-9.4/bin -d /data/= pg.old -D /data/pg --check *failure* Consult the last few lines of "pg_upgrade_server.log" for the probable cause of the failure. Performing Consistency Checks on Old Live Server ------------------------------------------------ Checking cluster versions ok Checking database user is a superuser ok Checking database connection settings ok Checking for prepared transactions ok Checking for reg* system OID user data types ok Checking for contrib/isn with bigint-passing mismatch ok Checking for invalid "line" user columns ok Checking for presence of required libraries ok Checking database user is a superuser ok Checking for prepared transactions ok *Clusters are compatible* When 9.3 is shut down: -bash-4.1$ /usr/pgsql-9.3/bin/pg_ctl stop -D /data/pg.old waiting for server to shut down.... done server stopped -bash-4.1$ pg_upgrade -b /usr/pgsql-9.3/bin -B /usr/pgsql-9.4/bin -d /data/= pg.old -D /data/pg --check Performing Consistency Checks ----------------------------- Checking cluster versions ok SQL command failed CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM pg_catalog.p= g_class c JOIN pg_catalog.pg_namespace n ON c.relnamespace =3D n.oid LEFT= OUTER JOIN pg_catalog.pg_index i ON c.oid =3D i.indexrelid WHERE relkind= IN ('r', 'm', 'i', 'S') AND i.indisvalid IS DISTINCT FROM false AND i.in= disready IS DISTINCT FROM false AND ((n.nspname !~ '^pg_temp_' AND n.= nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'infor= mation_schema', 'binary_upgrade', 'pg_toast') AND c.oid >=3D 16384) OR (n= .nspname =3D 'pg_catalog' AND relname IN ('pg_largeobject', 'pg_largeob= ject_loid_pn_index', 'pg_largeobject_metadata', 'pg_largeobject_metadata_oi= d_index') )); ERROR: cache lookup failed for type 1670699 Failure, exiting --_000_D2381B7B48445yguocventcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1A71C6CEE9475B4188298BF7D3CBADB4@cvent.com> Content-Transfer-Encoding: quoted-printable


From: Yun <yguo@cvent.com>
Date: Monday, October 5, 2015 at 12= :19 PM
To: "pgsql-admin-owner@postgresql.org" <<= a href=3D"mailto:pgsql-admin-owner@postgresql.org">pgsql-admin-owner@postgr= esql.org>
Subject: pg_upgrade from 9.3 to 9.4= fails

Hi,

I=92m trying to use pg_upgrade to upgrade 9.3 to 9.4. And I observed w= eird behavior, that if I have the old 9.3 server up and running the check w= ould pass, but if I shut it down it would fail.  Any idea why would it= behave this way? Is there a workaround for this issue?

With old 9.3 running:
-bash-4.1$ ps -ef | grep pg.old
postgres 16243     1  0 16:12 pts/0    00:00:= 00 /usr/pgsql-9.3/bin/postgres -D /data/pg.old
postgres 16261 15160  0 16:13 pts/0    00:00:00 grep pg= .old
-bash-4.1$ pg_upgrade -b /usr/pgsql-9.3/bin -B /usr/pgsql-9.4/bin -d /= data/pg.old -D /data/pg --check

*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions             &n= bsp;                     = ok
Checking database user is a superuser         &nbs= p;             ok
Checking database connection settings         &nbs= p;             ok
Checking for prepared transactions           =                ok
Checking for reg* system OID user data types       &nbs= p;        ok
Checking for contrib/isn with bigint-passing mismatch     &n= bsp; ok
Checking for invalid "line" user columns      = ;              ok
Checking for presence of required libraries        = ;         ok
Checking database user is a superuser         &nbs= p;             ok
Checking for prepared transactions           =                ok

*Clusters are compatible*

When 9.3 is shut down:

-bash-4.1$ /usr/pgsql-9.3/bin/pg_ctl stop -D /data/pg.old
waiting for server to shut down.... done
server stopped
-bash-4.1$ pg_upgrade -b /usr/pgsql-9.3/bin -B /usr/pgsql-9.4/bin -d /= data/pg.old -D /data/pg --check
Performing Consistency Checks
-----------------------------
Checking cluster versions             &n= bsp;                     = ok
SQL command failed
CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM pg_cata= log.pg_class c JOIN pg_catalog.pg_namespace n   ON c= .relnamespace =3D n.oid LEFT OUTER JOIN pg_catalog.pg_index i   ON c= .oid =3D i.indexrelid WHERE relkind IN ('r', 'm', 'i', 'S') AND  i.ind= isvalid IS DISTINCT FROM false AND  i.indisready IS DISTINCT FROM fals= e AND   ((n.nspname !~ '^pg_temp_' AND     n.nspname !~ '^pg_toast_temp_' AND     n.nspname NOT IN ('pg_catalog', 'in= formation_schema', 'binary_upg= rade', 'pg_toast') AND c.oid >=3D 16384)   OR (n.nspname =3D 'pg_catalog'= AND     relname IN ('pg_largeobject', 'pg_largeobject_loid_pn_in= dex', 'pg_largeobject_metadata', 'pg_largeobject_metadata_oid_index') ));
ERROR:  cache lookup failed for type 1670699

Failure, exiting



--_000_D2381B7B48445yguocventcom_--