mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-26 22:07:20 +02:00
a1ef01fe16
As of 9.2, with the --section option, it is very important that the concept of "pre data", "data", and "post data" sections of the output be honored strictly; else a dump divided into separate sectional files might be unrestorable. However, the dependency-sorting logic knew nothing of sections and would happily select output orderings that didn't fit that structure. Doing so was mostly harmless before 9.2, but now we need to be sure it doesn't do that. To fix, create dummy objects representing the section boundaries and add dependencies between them and all the normal objects. (This might sound expensive but it seems to only add a percent or two to pg_dump's runtime.) This also fixes a problem introduced in 9.1 by the feature that allows incomplete GROUP BY lists when a primary key is given in GROUP BY. That means that views can depend on primary key constraints. Previously, pg_dump would deal with that by simply emitting the primary key constraint before the view definition (and hence before the data section of the output). That's bad enough for simple serial restores, where creating an index before the data is loaded works, but is undesirable for speed reasons. But it could lead to outright failure of parallel restores, as seen in bug #6699 from Joe Van Dyk. That happened because pg_restore would switch into parallel mode as soon as it reached the constraint, and then very possibly would try to emit the view definition before the primary key was committed (as a consequence of another bug that causes the view not to be correctly marked as depending on the constraint). Adding the section boundary constraints forces the dependency-sorting code to break the view into separate table and rule declarations, allowing the rule, and hence the primary key constraint it depends on, to revert to their intended location in the post-data section. This also somewhat accidentally works around the bogus-dependency-marking problem, because the rule will be correctly shown as depending on the constraint, so parallel pg_restore will now do the right thing. (We will fix the bogus-dependency problem for real in a separate patch, but that patch is not easily back-portable to 9.1, so the fact that this patch is enough to dodge the only known symptom is fortunate.) Back-patch to 9.1, except for the hunk that adds verification that the finished archive TOC list is in correct section order; the place where it was convenient to add that doesn't exist in 9.1. |
||
|---|---|---|
| .. | ||
| po | ||
| .gitignore | ||
| common.c | ||
| compress_io.c | ||
| compress_io.h | ||
| dumpmem.c | ||
| dumpmem.h | ||
| dumputils.c | ||
| dumputils.h | ||
| keywords.c | ||
| Makefile | ||
| nls.mk | ||
| pg_backup_archiver.c | ||
| pg_backup_archiver.h | ||
| pg_backup_custom.c | ||
| pg_backup_db.c | ||
| pg_backup_db.h | ||
| pg_backup_directory.c | ||
| pg_backup_null.c | ||
| pg_backup_tar.c | ||
| pg_backup_tar.h | ||
| pg_backup.h | ||
| pg_dump_sort.c | ||
| pg_dump.c | ||
| pg_dump.h | ||
| pg_dumpall.c | ||
| pg_restore.c | ||
| README | ||
src/bin/pg_dump/README
Notes on pg_dump
================
1. pg_dump, by default, still outputs text files.
2. pg_dumpall forces all pg_dump output to be text, since it also outputs text into the same output stream.
3. The plain text output format cannot be used as input into pg_restore.
To dump a database into the new custom format, type:
pg_dump <db-name> -Fc > <backup-file>
or, to dump in TAR format
pg_dump <db-name> -Ft > <backup-file>
To restore, try
To list contents:
pg_restore -l <backup-file> | less
or to list tables:
pg_restore <backup-file> --table | less
or to list in a different order
pg_restore <backup-file> -l --oid --rearrange | less
Once you are happy with the list, just remove the '-l', and an SQL script will be output.
You can also dump a listing:
pg_restore -l <backup-file> > toc.lis
or
pg_restore -l <backup-file> -f toc.lis
edit it, and rearrange the lines (or delete some):
vi toc.lis
then use it to restore selected items:
pg_restore <backup-file> --use=toc.lis -l | less
When you like the list, type
pg_restore backup.bck --use=toc.lis > script.sql
or, simply:
createdb newdbname
pg_restore backup.bck --use=toc.lis | psql newdbname
TAR
===
The TAR archive that pg_dump creates currently has a blank username & group for the files,
but should be otherwise valid. It also includes a 'restore.sql' script which is there for
the benefit of humans. The script is never used by pg_restore.
Note: the TAR format archive can only be used as input into pg_restore if it is in TAR form.
(ie. you should not extract the files then expect pg_restore to work).
You can extract, edit, and tar the files again, and it should work, but the 'toc'
file should go at the start, the data files be in the order they are used, and
the BLOB files at the end.
Philip Warner, 16-Jul-2000
pjw@rhyme.com.au