Re: [GENERAL] Concurrency problem building indexes

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

Responses

Browse pgsql-hackers by date

  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