Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
We still have a little work to do on dependencies in parallel
pg_restore. The current test compares the candidate's locking
dependencies with those of the running jobs, and allows the candidate is
there isn't a match. That's not a broad enough test. The candidate will
block if there's a currently running CREATE INDEX command on the table,
for example, even though that doesn't require an exclusive lock. That's
not catastrophic, in that the restore doesn't fail, but it's fairly bad
because it reduces the achievable parallelism. Josh Berkus observed this
during testing on a very large restore.
Well, we certainly want to be able to run CREATE INDEXes in parallel,
so this would appear to require hard-wiring some conception of shared
versus exclusive lock into pg_restore. I think it might be a bit late
to consider that for 8.4.
I'm pretty sure I had the logic for this correct stuff originally, so
I'm going to go back and check that.
With luck it won't take long. It shouldn't hold up beta - it's just a
bug we need to fix, and with any luck I'll actually have it fixed in the
next few days.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
