Re: pg_restore dependencies

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

In response to

Responses

Browse pgsql-hackers by date

  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