| 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 21:33:50 |
| Message-ID: | 49DFBB3E.3040400@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:
>
>> 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.
>>
>
> 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.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-04-10 21:35:07 | Re: A renewed plea for inclusion of zone.tab |
| Previous Message | Tom Lane | 2009-04-10 21:25:15 | Re: pg_restore dependencies |