pgsql: Actually, all of parallel restore's limitations should be tested

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Actually, all of parallel restore's limitations should be tested
Date: 2011-08-29 02:29:45
Message-ID: E1Qxrbd-0002ex-OJ@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Actually, all of parallel restore's limitations should be tested earlier.

On closer inspection, whining in restore_toc_entries_parallel is really
much too late for any user-facing error case. The right place to do it
is at the start of RestoreArchive(), before we've done anything interesting
(suh as trying to DROP all the targets ...)

Back-patch to 8.4, where parallel restore was introduced.

Branch
------
REL8_4_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/ce530adf8e3a483e48a8d98ebe421b6963aa639c

Modified Files
--------------
src/bin/pg_dump/pg_backup_archiver.c | 38 ++++++++++++++++++++-------------
1 files changed, 23 insertions(+), 15 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2011-08-29 14:11:57 pgsql: Improve spinlock performance for HP-UX, ia64, non-gcc.
Previous Message Tom Lane 2011-08-29 01:53:54 pgsql: Be more user-friendly about unsupported cases for parallel pg_re