Skip site navigation (1) Skip section navigation (2)

pgsql: Improve parallel restore's ability to cope with selective restore

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Improve parallel restore's ability to cope with selective restore
Date: 2010-08-21 13:59:44
Message-ID: 20100821135944.B66057541D7@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Log Message:
-----------
Improve parallel restore's ability to cope with selective restore (-L option).

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.

Modified Files:
--------------
    pgsql/src/bin/pg_dump:
        pg_backup_archiver.c (r1.187 -> r1.188)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_archiver.c?r1=1.187&r2=1.188)

pgsql-committers by date

Next:From: Tom LaneDate: 2010-08-21 13:59:50
Subject: pgsql: Improve parallel restore's ability to cope with selective restore
Previous:From: Magnus HaganderDate: 2010-08-21 13:18:02
Subject: pgsql: Adjust regression tests for previous commit, that I forgot to

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group