Re: [GENERAL] Using an SMP machine to make multiple indices on the same

Tom Lane wrote:
> 
> Martin Weinberg <weinberg@osprey.astro.umass.edu> 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.

As I've already mentioned many times I never agree with you.

> 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?

Hmm the excluive row level lock by FOR UPDATE is too strong
in this case. OK I would change IndexesAreActive() to not
acquire a lock on the pg_class tuple for user tables because
reindex doesn't need to handle relhasindex for user tables
since 7.1.

regards,
Hiroshi Inoue