Skip site navigation (1) Skip section navigation (2)

Re: [BUGS] problem creating index in 6,5,3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: kdebisschop(at)range(dot)infoplease(dot)com
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: [BUGS] problem creating index in 6,5,3
Date: 2000-01-04 22:00:18
Message-ID: 14732.947023218@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-general
Karl DeBisschop <kdebisschop(at)range(dot)infoplease(dot)com> writes:
> sterno.infoplease.com:/u/kdebisschop> psql -p 5433 webusers -c "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.
> [2]+  Done                    psql -p 5433 webusers -c "CREATE INDEX zdaily_date_n ON daily (date,n)"
> sterno.infoplease.com:/u/kdebisschop> psql -p 5433 webusers -c "CREATE INDEX zdaily_id ON daily USING hash (id)"
> ERROR:  cannot open segment 1 of relation zdaily_id
> sterno.infoplease.com:/u/kdebisschop> 

> Still no core dump.  Each of these takes an hour or so to croak.

Puzzling...

The lack of a core dump is probably the thing we ought to be paying
attention to here --- most ordinary sorts of unexpected-backend-crash
bugs should dump core.

One possibility is that the kernel is killing that backend process,
most likely for having exceeded a system limit on runtime or disk blocks
written; do you have such limits enabled on your machine?  Or maybe it
is running out of memory/swap space; how big does the process get before
terminating?

Another possibility is that the backend has detected a fatal error
condition and is doing a more-or-less-orderly shutdown.  However if that
were true then there ought to be an error message in the postmaster
logfile; I see no such message in your prior mails.

Also, I just noticed that you are trying to index a "text" field.
How long are the entries in the field?  6.5.* does not have adequate
defenses against overly-long index entries --- the maximum safe size
is 2700 bytes IIRC, but this isn't tested for in the current release.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Dirk LutzebaeckDate: 2000-01-05 07:47:28
Subject: Re: [BUGS] vacuum analyze corrupts db with larger tuples (< 8k)
Previous:From: Karl DeBisschopDate: 2000-01-04 20:01:32
Subject: Re: [BUGS] problem creating index in 6,5,3

pgsql-general by date

Next:From: Jim MercerDate: 2000-01-04 22:08:22
Subject: backend grows during cursor/select/fetch (memory leak?)
Previous:From: Bruce MomjianDate: 2000-01-04 21:48:45
Subject: Re: [GENERAL] Future of PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group