Re: --single-transaction hack to pg_upgrade does not work

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: --single-transaction hack to pg_upgrade does not work
Date: 2012-12-01 12:43:17
Message-ID: 50B9FB65.5090601@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/30/2012 11:10 PM, Tom Lane wrote:
> Some of the buildfarm members are failing the pg_upgrade regression test
> since commit 12ee6ec71f8754ff3573711032b9b4d5a764ba84. I can duplicate
> it here, and the symptom is:
>
> pg_restore: creating TYPE float8range
> pg_restore: creating TYPE insenum
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 978; 1247 16584 TYPE insenum tgl
> pg_restore: [archiver (db)] could not execute query: ERROR: ALTER TYPE ... ADD cannot run inside a transaction block
> Command was:
> -- For binary upgrade, must preserve pg_type oid
> SELECT binary_upgrade.set_next_pg_type_oid('16584'::pg_catalog.oid);
>
> I have not investigated why it apparently passes some places; this looks
> to me like a guaranteed failure.
>
>

Testing pg_upgrade has only been in buildfarm releases since September
28, and even then is optional, although enabled by default in the sample
config file. Looks like even I need to upgrade a few of my animals to do
it. It probably needs to improve its error logging though.

Seems odd not to have run "make check" before committing, though.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-12-01 13:45:20 Tablespaces in the data directory
Previous Message Pavel Stehule 2012-12-01 12:14:08 Re: proposal: fix corner use case of variadic fuctions usage