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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-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

Browse pgsql-bugs by date

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

Browse pgsql-general by date

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