From: | Joseph Tate <jtate(at)dragonstrider(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | pg_restore problems and suggested resolution |
Date: | 2004-02-13 20:49:55 |
Message-ID: | 402D3873.2070806@dragonstrider.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've got a custom (-Fc) pg_dump output from a fairly complex 7.2.x db
schema. It has such things as user defined functions, OIDs, rules and
triggers, etc. When I try to restore it to a 7.4 database, it fails
because of some differences in the CREATE TABLE commands (I've got a
column of type TIMESTAMP WITH TIMEZONE and the DEFAULT's default type is
TEXT).
Also, when the data is restored, and the OIDs are "fixed", the rules and
triggers aren't disabled on the columns/tables that are UPDATEd during
the restore process, so those rules and triggers fire. Since these
rules and triggers are designed to be executed within a transaction that
includes a call to a setup type function which creates a temporary
table, the rules fail.
I've filed a bug on the OID problem before, but have so far been able to
work around the problem. However, when tied to the CREATE TABLE error
above, I can't get this data restored. Usually what I do is grep -v the
rules and triggers from the DB schema restore, restore the data, then
restore the rules and triggers. However now I can't restore the schema
at all. I could rebuild the db with my ddl without the rules and
triggers, and then restore the data, but I'd rather fix this at the source.
I propose pg_restore --disable-triggers be modified so that triggers are
disabled on the tables that OID fixing is going to UPDATE. I'll
hopefully have a patch against REL7_4_STABLE for this soon, but I
haven't started it yet. Does anyone have any suggestions? Has someone
already done this in HEAD so that it can be backported to 7.4?
Joseph
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-02-13 21:20:27 | Re: Transaction aborts on syntax error. |
Previous Message | Joe Conway | 2004-02-13 17:30:38 | Re: dblink - custom datatypes NOW work :) |