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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers