Re: DB Import Error... - Mailing list pgsql-admin

From Gnanakumar
Subject Re: DB Import Error...
Date
Msg-id 003c01cbf80e$6e5dc220$4b194660$@com
Whole thread Raw
In response to Re: DB Import Error...  (Marcelo Leite <leite.marcelo@gmail.com>)
List pgsql-admin
> when i said "search for the  problematic constraint" i meant to open the
file in a text editor and search for the problematic constraint.

Yes,  I've even opened the dump file and analyzed those constraints.  In
fact, I've already explained in detail about my observations here:
http://archives.postgresql.org/pgsql-admin/2011-04/msg00033.php

As I said in the above link, though many FK constraints were dropped very
long (years) back in our application, but its associated "constraint
triggers" were not dropped properly by PostgreSQL from "pg_trigger" table in
v8.2.3.  After understanding about PostgreSQL system catalog table
(particularly pg_class, pg_trigger, pg_constraint), I wrote a function on my
own to delete the FK constraints that are still referred in pg_trigger
table.

After executing the below function in v8.2.3, I took pg_dump in v8.2.3 and
then imported the SQL dump into v9.0.3.  Now, I don't see any errors while
importing in v9.0.3.

NOTE: Previously, when there was errors while importing in v9.0.3, I could
see all those *dropped* FK constraints were again automatically *recreated*
in v9.0.3.  I confirmed this from 2 places: psql (using \d) and pgAdmin II
tool.  But after executing the below function in v8.0.3 before taking
pg_dump and then import in v9.0.3, I don't see any errors now and also at
the same time, I don't see those dropped FK constraints
reappearing/recreated here.

Any advice/suggestion/remarks/alternatives to my approach are highly
appreciated.

FUNCTION:
CREATE OR REPLACE FUNCTION delete_dropped_fk_constraints_from_pg_trigger()
RETURNS numeric AS'
DECLARE
    v_tgconstrname        VARCHAR;
    v_table1        VARCHAR;
    v_table2        VARCHAR;

    v_child_trigger_count    NUMERIC := 0;
    v_parent_trigger_count    NUMERIC := 0;
C1 CURSOR IS
    SELECT
        DISTINCT tgconstrname,
        (select relname from pg_class where oid = tgrelid) as
table1,
        (select relname from pg_class where oid = tgconstrrelid) as
table2
    FROM
        pg_trigger
    WHERE
        tgisconstraint = true
        AND tgconstrname IS NOT NULL
        AND LENGTH(tgconstrname) > 0
        AND tgconstrname != ''<unnamed>''
        AND tgconstrname NOT IN
            (SELECT conname FROM pg_constraint
                WHERE contype = ''f'')
    ORDER BY 1;
BEGIN
    OPEN C1;
    LOOP
    FETCH C1 INTO v_tgconstrname, v_table1, v_table2;

        IF NOT FOUND THEN
            EXIT;
        END IF;

        RAISE NOTICE ''FK Constraint Name=%, Table1=%, Table2=%'',
v_tgconstrname, v_table1, v_table2;

        SELECT COUNT(*) INTO v_child_trigger_count FROM pg_trigger
        WHERE tgrelid = (SELECT oid FROM pg_class WHERE relname =
LOWER(v_table1)) AND
                tgconstrname = LOWER(v_constr_name);

        SELECT COUNT(*) INTO v_parent_trigger_count FROM pg_trigger
        WHERE tgrelid = (SELECT oid FROM pg_class WHERE relname =
LOWER(v_table2)) AND
                tgconstrname = LOWER(v_constr_name);

        DELETE FROM pg_trigger WHERE LOWER(tgconstrname) =
LOWER(v_constr_name) AND tgrelid IN
        (SELECT oid FROM pg_class WHERE relname IN
(LOWER(v_table1),LOWER(v_table2)));

        UPDATE pg_class SET reltriggers = reltriggers -
v_child_trigger_count WHERE relname = LOWER(v_table1);

        IF (v_table1 <> v_table2) THEN -- This condition is checked
for self-referencing FK constraints
            UPDATE pg_class SET reltriggers = reltriggers -
v_parent_trigger_count WHERE relname = LOWER(v_table2);
        END IF;

    END LOOP;
    CLOSE C1;

    RETURN 1;
END;'
LANGUAGE 'plpgsql';

SELECT delete_dropped_fk_constraints_from_pg_trigger();



pgsql-admin by date:

Previous
From: Selva manickaraja
Date:
Subject: Re: Too many WAL(s) despite low transaction
Next
From: "David Roland"
Date:
Subject: Re: pg_start_backup - backups