Re: [GENERAL] Concurrency problem building indexes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Concurrency problem building indexes
Date
Msg-id 19159.1145977085@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Concurrency problem building indexes  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
Responses Re: [GENERAL] Concurrency problem building indexes  (Wes <wespvp@syntegra.com>)
List pgsql-hackers
"Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.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


pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas DCP SD"
Date:
Subject: Re: [GENERAL] Concurrency problem building indexes
Next
From: REYNAUD Jean-Samuel
Date:
Subject: FOR UPDATE lock problem ?