Re: table dump

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Jodi Kanter <jkanter(at)virginia(dot)edu>
Cc: Postgres Admin List <pgsql-admin(at)postgresql(dot)org>
Subject: Re: table dump
Date: 2002-04-09 15:53:25
Message-ID: 20020409085143.Y94187-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


On Tue, 9 Apr 2002, Jodi Kanter wrote:

> I just completed a data only dump of a table by using the following command:
>
> pg_dump genex -Rau -t species > species.sql
>
> I noticed that the first line of the file seems to be disabling some
> postgres trigger. It reads:
>
> UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" = 'species';
>
> Then all the data is listed.
>
> At the end of the file the triggers are enabled again with the
> following command:
>
> UPDATE pg_class SET reltriggers = (SELECT count(*) FROM pg_trigger
> where pg_class.oid = tgrelid) WHERE relname = 'species';
>
> Can someone explain why this is happening? The problem is that I am
> coping this dump into another schema creation file that I have. I want
> the data from this particular file included in with my new database.
> However, I am creating this database with a user account so that all
> tables will be owned by that user. I think the problem here is that
> this trigger stuff requires that you be signed in as postgres in order
> to do anything with the pg_class table. correct?

You'd need to be a superuser I'd guess. The reason for those statmenets
is to turn off foreign key constraints during the load of what's assumed
to be correct data since it came from a dump. You can ignore them if you
don't have any or don't mind having the constraints run.

In response to

  • table dump at 2002-04-09 14:10:19 from Jodi Kanter

Browse pgsql-admin by date

  From Date Subject
Next Message Jean-Christophe ARNU (JX) 2002-04-10 08:12:58 Timestamps and performance problems on queries.
Previous Message Jodi Kanter 2002-04-09 14:10:19 table dump