From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_restore dependencies |
Date: | 2009-04-10 20:57:26 |
Message-ID: | 49DFB2B6.6080207@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-04-10 20:58:09 | Re: Windows installation service |
Previous Message | Kevin Grittner | 2009-04-10 20:46:09 | Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabledinplpgsql |