From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | panam <panam(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: fix for pg_upgrade |
Date: | 2011-09-28 12:21:54 |
Message-ID: | 201109281221.p8SCLsW02391@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
panam wrote:
> Here are all generated log files.
>
> I just removed all other DBs except gnucash (which includes the accounts
> table), but the issue also emerges with other DBs.
> Upgraded the 9.1 instance to the new build (9.1.1.) as well but this
> apparently did not change anything.
> PG versions are (including generated logs):
> PostgreSQL 9.0.4, compiled by Visual C++ build 1500, 64-bit
> PostgreSQL 9.1.0, compiled by Visual C++ build 1500, 64-bit:
> http://postgresql.1045698.n5.nabble.com/file/n4848829/pg_upgrade_9.1.0.zip
> pg_upgrade_9.1.0.zip
> PostgreSQL 9.1.1, compiled by Visual C++ build 1500, 64-bit:
> http://postgresql.1045698.n5.nabble.com/file/n4848829/pg_upgrade_9.1.1.zip
> pg_upgrade_9.1.1.zip
> I hope that is what you meant with "pg_upgrade log file".
OK, so it fails for all tables and you are using the newest version.
Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
just broken on Windows.
Perhaps the variables set by pg_upgrade_support.so are not being passed
into the server variables? I know pg_upgrade 9.0.X worked on Windows
because EnterpriseDB did extensive testing recently on this. Has
anyone used pg_upgrade 9.1.X on Windows?
As far as a log file, you need you to use '-l log' and email me that
file.
As far as testing, I wonder if we need to load in pg_upgrade_support on
Windows, and rerun some of the pg_dumpall SQL create table statements to
see why the pg_class.oid and others are not getting set. For example,
this:
-- For binary upgrade, must preserve pg_class oids
SELECT binary_upgrade.set_next_heap_pg_class_oid('465783'::pg_catalog.oid);
SELECT binary_upgrade.set_next_toast_pg_class_oid('465786'::pg_catalog.oid);
SELECT binary_upgrade.set_next_index_pg_class_oid('465788'::pg_catalog.oid);
CREATE TABLE accounts (
guid character varying(32) NOT NULL,
name character varying(2048) NOT NULL,
account_type character varying(2048) NOT NULL,
commodity_guid character varying(32),
commodity_scu integer NOT NULL,
non_std_scu integer NOT NULL,
parent_guid character varying(32),
code character varying(2048),
description character varying(2048),
hidden integer,
placeholder integer
);
should set the accounts pg_class.oid as 465783. The server will need to
be started with -b and this will disable autovacuum. Can someone on
Windows try this?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2011-09-28 12:25:09 | Re: synchronized snapshots |
Previous Message | Bruce Momjian | 2011-09-28 12:11:32 | Re: pg_upgrade automatic testing |