| From: | tgl(at)postgresql(dot)org (Tom Lane) |
|---|---|
| To: | pgsql-committers(at)postgresql(dot)org |
| Subject: | pgsql: When doing a parallel restore, we must guard against out-of-range |
| Date: | 2010-01-19 18:39:19 |
| Message-ID: | 20100119183919.E05B57541B9@cvs.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Log Message:
-----------
When doing a parallel restore, we must guard against out-of-range dependency
dump IDs, because the array we're using is sized according to the highest
dump ID actually defined in the archive file. In a partial dump there could
be references to higher dump IDs that weren't dumped. Treat these the same
as references to in-range IDs that weren't dumped. (The whole thing is a
bit scary because the missing objects might have been part of dependency
chains, which we won't know about. Not much we can do though --- throwing
an error is probably overreaction.)
Also, reject parallel restore with pre-1.8 archive version (made by pre-8.0
pg_dump). In these old versions the dependency entries are OIDs, not dump
IDs, and we don't have enough information to interpret them.
Per bug #5288 from Jon Erdman.
Modified Files:
--------------
pgsql/src/bin/pg_dump:
pg_backup_archiver.c (r1.177 -> r1.178)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_archiver.c?r1=1.177&r2=1.178)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-01-19 18:39:26 | pgsql: When doing a parallel restore, we must guard against out-of-range |
| Previous Message | Tom Lane | 2010-01-19 16:33:33 | pgsql: Fix thinko in my recent change to put an explicit argisrow field |