Martin Weinberg <[EMAIL PROTECTED]> writes: > Yes, I understand locking the table, but empirically, two index > creations will not run simultaneously on the same table.
Hmm, on trying it you are right. The second index creation blocks here: #6 0x1718e0 in XactLockTableWait (xid=17334) at lmgr.c:344 #7 0x9e530 in heap_mark4update (relation=0xc1be62f8, tuple=0x7b03b7f0, buffer=0x7b03b828) at heapam.c:1686 #8 0xcb410 in LockClassinfoForUpdate (relid=387785, rtup=0x7b03b7f0, buffer=0x7b03b828, confirmCommitted=0 '\000') at index.c:1131 #9 0xcb534 in IndexesAreActive (relid=387785, confirmCommitted=1 '\001') at index.c:1176 #10 0xf0f04 in DefineIndex (heapRelationName=0x400aab20 "tenk1", indexRelationName=0x400aab00 "anotherj", accessMethodName=0x59f48 "btree", attributeList=0x400aab80, unique=0, primary=0, predicate=0x0, rangetable=0x0) at indexcmds.c:133 #11 0x17e118 in ProcessUtility (parsetree=0x400aaba0, dest=Remote) at utility.c:905 Essentially it's trying to do a SELECT FOR UPDATE on the pg_class tuple of the relation before it starts building the index. I have opined before that LockClassinfoForUpdate is a mistake that shouldn't exist at all, since acquiring the proper lock on the relation ought to be sufficient. I see no need for locking the pg_class tuple, and certainly none for doing so at the beginning of the operation rather than the end. Hiroshi, I think you defended it last time; any comments? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly