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
