Re: fix for pg_upgrade - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: fix for pg_upgrade |
Date | |
Msg-id | 201109281221.p8SCLsW02391@momjian.us Whole thread Raw |
In response to | Re: fix for pg_upgrade (panam <panam@gmx.net>) |
Responses |
Re: fix for pg_upgrade
Re: fix for pg_upgrade |
List | 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 oidsSELECT 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);CREATETABLE accounts ( guid character varying(32)NOT NULL, name character varying(2048) NOT NULL, account_type character varying(2048) NOT NULL, commodity_guidcharacter varying(32), commodity_scu integer NOT NULL, non_std_scu integer NOT NULL, parent_guid charactervarying(32), code character varying(2048), description character varying(2048), hidden integer, placeholderinteger); 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
pgsql-hackers by date: