Skip site navigation (1) Skip section navigation (2)

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

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Martin Weinberg" <weinberg(at)osprey(dot)astro(dot)umass(dot)edu>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Using an SMP machine to make multiple indices on the same
Date: 2001-10-24 15:23:47
Message-ID: EKEJJICOHDIEMGPNIFIJAEEIFLAA.Inoue@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
> -----Original Message-----
> From: Hiroshi Inoue
>
> Tom Lane wrote:
> >
> > Martin Weinberg <weinberg(at)osprey(dot)astro(dot)umass(dot)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.

In the end, I changed DefineIndex() to not call IndexesAreActive().

regards,
Hiroshi Inoue


In response to

Responses

pgsql-hackers by date

Next:From: ArguileDate: 2001-10-24 15:38:38
Subject: New default ignored by pre-exising insert rulesets.
Previous:From: Philip WarnerDate: 2001-10-24 15:14:22
Subject: Can't cast bigint to smallint?

pgsql-general by date

Next:From: Keary SuskaDate: 2001-10-24 15:24:49
Subject: Re: Free PostgreSQL book
Previous:From: Hiroshi InoueDate: 2001-10-24 15:23:16
Subject: Re: Writing BLOBS to pgsql via ODBC using VB

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group