mirror of
https://github.com/postgres/postgres.git
synced 2026-02-27 11:50:33 -05:00
c5d6d5bc6d
The original coding tended to break down in the face of modified restore orders, as shown in bug #5626 from Albert Ullrich, because it would flip over into parallel-restore operation too soon. That causes problems because we don't have sufficient dependency information in dump archives to allow safe parallel processing of SECTION_PRE_DATA items. Even if we did, it's probably undesirable to allow that to override the commanded restore order. To fix the problem of omitted items causing unexpected changes in restore order, tweak SortTocFromFile so that omitted items end up at the head of the list not the tail. This ensures that they'll be examined and their dependencies will be marked satisfied before we get to any interesting items. In HEAD and 9.0, we can easily change restore_toc_entries_parallel so that all SECTION_PRE_DATA items are guaranteed to be processed in the initial serial-restore loop, and hence in commanded order. Only DATA and POST_DATA items are candidates for parallel processing. For them there might be variations from the commanded order because of parallelism, but we should do it in a safe order thanks to dependencies. In 8.4 it's much harder to make such a guarantee. I settled for not letting the initial loop break out into parallel processing mode if it sees a DATA/POST_DATA item that's not to be restored; this at least prevents a non-restorable item from causing premature exit from the loop. This means that 8.4 will be more likely to fail given a badly-ordered -L list than 9.x, but we don't really promise any such thing will work anyway. |
||
|---|---|---|
| .. | ||
| po | ||
| common.c | ||
| dumputils.c | ||
| dumputils.h | ||
| keywords.c | ||
| Makefile | ||
| nls.mk | ||
| pg_backup.h | ||
| pg_backup_archiver.c | ||
| pg_backup_archiver.h | ||
| pg_backup_custom.c | ||
| pg_backup_db.c | ||
| pg_backup_db.h | ||
| pg_backup_files.c | ||
| pg_backup_null.c | ||
| pg_backup_tar.c | ||
| pg_backup_tar.h | ||
| pg_dump.c | ||
| pg_dump.h | ||
| pg_dump_sort.c | ||
| pg_dumpall.c | ||
| pg_restore.c | ||
| README | ||
$PostgreSQL: pgsql/src/bin/pg_dump/README,v 1.7 2008/03/21 13:23:28 momjian Exp $
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