From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_restore dependencies |
Date: | 2009-04-10 22:44:12 |
Message-ID: | 49DFCBBC.8070205@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Tom Lane wrote:
>>
>>> Doesn't that eliminate any chance of running two CREATE INDEXes
>>> concurrently on the same table?
>>>
>
>
>> No, since neither of them will have any locking dependencies, which are
>> only for items that take an exclusive lock on the table(s), such as FK
>> constraints.
>>
>
> In that case a CREATE INDEX would also fail to be seen as conflicting
> with an ALTER ADD FOREIGN KEY, which I thought was the nub of Josh's
> complaint.
>
>
>
No it won't.
What you're missing is that we need to compare the lockdeps of each item
(i.e. both the candidate item and the running item) with all the deps
(not just the lockdeps) of the other item. If neither item has any
lockdeps there will be no conflict. This will allow concurrent index
creation, since neither item will have any lockdeps. But it will prevent
us selecting a create index that conflicts with a running FK creation or
vice versa.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-10 22:57:16 | Re: pg_restore dependencies |
Previous Message | Tom Lane | 2009-04-10 21:59:31 | Re: pg_restore dependencies |