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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Martin Weinberg" <weinberg(at)osprey(dot)astro(dot)umass(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Using an SMP machine to make multiple indices on the same
Date: 2001-10-24 17:49:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> In the end, I changed DefineIndex() to not call IndexesAreActive().

I saw that.  But is it a good solution?  If someone has deactivated
indexes on a user table (ie turned off relhasindex), then creating a
new index would activate them again, which would probably be bad.

I have realized that this code is wrong anyway, because it doesn't
acquire ShareLock on the relation until far too late; all the setup
processing is done with no lock at all :-(.  LockClassinfoForUpdate
provided a little bit of security against concurrent schema changes,
though not enough.

Also, I'm now a little worried about whether concurrent index creations
will actually work.  Both CREATE INDEX operations will try to update
the pg_class tuple to set relhasindex true.  Since they use
simple_heap_update for that, the second one is likely to fail
because simple_heap_update doesn't handle concurrent updates.

I think what we probably want is

	1. Acquire ShareLock at the very start.

	2. Check for indexes present but relhasindex = false,
	   if so complain.

	3. Build the index.

	4. Update pg_class tuple, being prepared for concurrent
	   updates (ie, do NOT use simple_heap_update here).

I still don't see any value in LockClassinfoForUpdate, however.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-10-24 17:55:20
Subject: pgindent run
Previous:From: Tom LaneDate: 2001-10-24 16:59:45
Subject: Re: storing binary data

pgsql-general by date

Next:From: Bruce MomjianDate: 2001-10-24 17:57:39
Subject: Re: Progress, anything in common with PostgreSQl besides clever
Previous:From: John HaslerDate: 2001-10-24 17:41:11
Subject: Re: GUID in postgres

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