From: | Dan Langille <dan(at)langille(dot)org> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | man pg-dump + triggers |
Date: | 2003-03-11 04:00:53 |
Message-ID: | 20030310224621.B62620@xeon.unixathome.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I found this hard to comprehend upon the first reading:
When doing a data only dump, pg_dump emits queries to disable triggers on
user tables before inserting the data and queries to re-enable them after
the data has been inserted. If the restore is stopped in the middle, the
system catalogs may be left in the wrong state.
I first thought that pg_dump issues a command to disable triggers. What
it meant, I think, is that pg_dump includes those commands within the
output. Those commands are actually processed/issued by pg_restore (or
perhaps psql in a 'psql mydb < mydump.sql' fashion.
If my impressions are correct, then I think the following is more
appropriate:
When doing a data-only dump, pg_dump will output data insert statements
that are wrapped with a pair of commands to first disable and then re-enable
triggers on user tables. If the restore is stopped in the middle
of the inserts, the system catalogs may be left in the wrong state.
NOTE: I am not sure that "catalogs may be left in the wrong state" is the
correct phrase to use.
cheers
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-11 05:12:51 | Re: Bug #890: only one user per process in libpq with krb5 auth |
Previous Message | Trever L. Adams | 2003-03-10 18:29:49 | bug with vacuum analyze? |