c2c-oerpscenario team mailing list archive
-
c2c-oerpscenario team
-
Mailing list archive
-
Message #24239
Re: [Bug 782688] [NEW] OpenERP table cannot be upgraded with pg_upgrade
Found a link:
http://postgresql.1045698.n5.nabble.com/BUG-6024-pg-dump-won-t-dump-ALTERed-
inherited-fields-td4390166.html
--
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/782688
Title:
OpenERP table cannot be upgraded with pg_upgrade
Status in OpenERP Server:
New
Bug description:
I tried upgrading my postgres from 8.4 to 9.0 which lead to the
following error:
Restoring database schema to new cluster
> > psql:/usr/lib/postgresql/9.0/bin/pg_upgrade_dump_db.sql:24606: ERROR:
> > column "name" in child table must be marked NOT NULL
looking at the dump file I see the following:
-- For binary upgrade, must preserve relfilenodes
SELECT binary_upgrade.set_next_heap_relfilenode('88788'::pg_catalog.oid);
SELECT binary_upgrade.set_next_toast_relfilenode('88795'::pg_catalog.oid);
SELECT binary_upgrade.set_next_index_relfilenode('88797'::pg_catalog.oid);
CREATE TABLE ir_act_url (
id integer DEFAULT nextval('ir_actions_id_seq'::regclass) NOT NULL,
name character varying(64) DEFAULT ''::character varying,
type character varying(32) DEFAULT 'window'::character varying NOT NULL,
usage character varying(32) DEFAULT NULL::character varying,
url text NOT NULL,
target character varying(64) NOT NULL,
create_uid integer,
create_date timestamp without time zone,
write_date timestamp without time zone,
write_uid integer
);
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'id'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'name'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'type'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'usage'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'create_uid'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'create_date'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'write_date'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, recreate inherited column.
UPDATE pg_catalog.pg_attribute
SET attislocal = false
WHERE attname = 'write_uid'
AND attrelid = 'ir_act_url'::pg_catalog.regclass;
-- For binary upgrade, set up inheritance this way.
24606: ALTER TABLE ONLY ir_act_url INHERIT ir_actions;
the full discussion of this issue can be found in several threads on
the PGAdmin mailing list here:
http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=34980
I am not going to attach the dump since this is public and it contains
other data from other databases. Please email me if you require the
dump.
The analysis from a developer is:
It seems somehow your schema is corrupt --- it is pg_dump that is
>> failing, and threfore pg_upgrade. We need to find out how you got into
>> that state. Do a manual pg_dump and see what table is being referenced
>> on line 24606. It is saying that that table has a 'name' column that is
>> not marked NOT NULL, while the parent table does have a NOT NULL
>> specification. Those should match. I don't remember hearing about a
>> bug in that area of the code.
so somehow OpenERP is creating this, making pg_dump fail, which I
would consider an OpenERP bug. Also PGsql is allowing this to happen,
which is probably also a PGSql bug. I am sending this report to the
postgres developer I am working with on this.
References