Cannot index large table in 6.5.3 on Linux

From: Karl DeBisschop <kdebisschop(at)range(dot)infoplease(dot)com>
To: pgsql-general(at)postgreSQL(dot)org
Subject: Cannot index large table in 6.5.3 on Linux
Date: 1999-12-21 13:16:11
Message-ID: 199912211316.IAA01837@skillet.infoplease.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general


This was originally posted on bugs, to no avail. Maybe someone else
in the general mailing list has had similar problems and can shed some
light.

Basically, the subject say it all. I am trying to index a text field
in a somehwhat large table (approx 1GB). We have had this database
running for over a year now, and we have never had this problem until
upgrading to 6.5.3. Most recently, we were running 6.5.1 and the
table indexed fine. We do a lot of inserts on the table each night,
so we drop the index first for performance reasons. Since upgrading
to 6.5.3, we have not been able to recreate the index (However, an
index on a char(1) field and a joint index on (date,integer) both do
work -- they generate 200000000 byte indexes.)

When we moved to 6.5.3, we vacuumed the database just to be make sure
there were no problems. That worked fine. It's just the creation
that seems to be the problem.

I have watched the process of creation. It seems to get most or all
of the way through the process - it creates an index file about the
size of the old one (~750000000 bytes). Then we get:

webusers=> CREATE INDEX zdaily_id ON daily (id);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.

and everything is deleted.

The original 6.5.3 install was from the RPM. I have recompiled the
database on the machine in question, and still the same result. I
have tried both btree and hash indexes, still the same result. At
first, the table spanned two files. I moved old data out and shrunk
it to one file. Still the same result.

I have not been able to cause postmaster to generate a core when it
dies.

So no I'm stumped.

I am running on 1 dual-processor VA-linux machine:

Architecture (example: Intel Pentium) :
Intel Pentium III 450MHz x2 SMP

Operating System (example: Linux 2.0.26 ELF) :
Linux version 2.2.7-1.23smp (root(at)jiangsup(dot)var(dot)com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Thu Jul 8 15:23:01 PDT 1999

PostgreSQL version (example: PostgreSQL-6.5.2): PostgreSQL-6.5.3
(from postgresql-6.5.3-1.i386.rpm distributed by
www.POstgreSQL.org, then compiled on local machine)

Compiler used (example: gcc 2.8.0) :
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

I would appreciate any suggestions on additional possibilities for
diagnosis or repair.

--
Karl DeBisschop <kdebisschop(at)alert(dot)infoplease(dot)com>
617.832.0332 (Fax: 617.956.2696)

Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper

Netsaint Plugins Development
http://netsaintplug.sourceforge.net

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrzej Mazurkiewicz 1999-12-21 13:20:49 Inheritance of functions.
Previous Message Laurent LEVIER 1999-12-17 22:09:49 PostregSQL 6.5.3 on Linux RedHat 6.1/Ultra1 Sparc (sun4u)

Browse pgsql-general by date

  From Date Subject
Next Message J. Roeleveld 1999-12-21 15:06:14 item descriptions in psql
Previous Message Herouth Maoz 1999-12-21 12:08:50 Re: [GENERAL] char(xx) problem