From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Wes" <wespvp(at)syntegra(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "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 08:25:08 |
Message-ID: | E1539E0ED7043848906A8FF995BDA579F31C06@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > [ shrug... ] Worksforme.
> >
> > There is a short interval at the end of the first CREATE INDEX on
the
> > table where the problem would happen if another CREATE INDEX tries
to
> > modify the pg_class row before the first one's committed.
> I did a pg_dumpall and removed the index creation commands. The first
time
> I run the index build, I usually get at least one occurrence.
I think that narrows it down nicely. You create the table, load rows,
then without
analyze create the indexes, thus pg_class is not up to date, and the
update
needs to be done.
My answer to this would be to (have an option to) ommit this relpages
and reltuples update. It is imho not the task of create index to update
statistics
in the first place. I have been burnt by that behavior when creating
indexes on empty
tables in Informix and never liked it (iirc pg has a workaround for
empty tables though).
Wes, you could most likely solve your immediate problem if you did an
analyze before
creating the indexes.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-04-25 10:16:37 | Re: Checking assumptions |
Previous Message | Gevik Babakhani | 2006-04-25 08:15:55 | Re: TODO Item: ACL_CONNECT |