Re: [GENERAL] Concurrency problem building indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Wes" <wespvp(at)syntegra(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Concurrency problem building indexes
Date: 2006-04-25 14:58:05
Message-ID: 19159.1145977085@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> writes:
> My answer to this would be to (have an option to) ommit this relpages
> and reltuples update.

Wouldn't help, unless you want to get rid of relhasindex too.

> Wes, you could most likely solve your immediate problem if you did an
> analyze before creating the indexes.

No, because that would install an approximate tuple count that the first
CREATE INDEX would (most likely) still want to replace.

The best I can gather from Wes' mail is that he's somehow getting a
higher-than-chance probability that the first two CREATE INDEX commands
finish at almost exactly the same time, and thus neither one of them
sees the pg_class row as already updated with the correct values.
I can't think of any effect in the PG code that would make CREATE INDEX
commands tend to converge rather than diverge, so maybe there is some
external effect here. Wes, is your machine a dual processor by any
chance? Which OS X version exactly?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-04-25 15:09:10 Re: Google SoC--Idea Request
Previous Message Zeugswetter Andreas DCP SD 2006-04-25 14:55:00 Re: [GENERAL] Concurrency problem building indexes