| 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: | Whole Thread | Raw Message | 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? |