Tom Lane wrote:
Andrew Dunstan <and...@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
