Josh Berkus wrote:
Tom, Andrew,
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.
FWIW, I've tested 3 moderately complex databases with this, and the
locking issue happens on every one. As a result, getting more than 3
cores of scalability on any fairly complex DB isn't possible without
fixing this.
Yeah. I think the correct logic is roughly this: When considering if a
candidate item has a locking conflict with a running item, then if
*either* of them has a locking dependency that coincides with *any*
dependency of the other item, then the candidate is rejected. The
principle is that we don't give any item a chance to block on a lock.
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
