Re: [BUGS] problem creating index in 6,5,3
От | Tom Lane |
---|---|
Тема | Re: [BUGS] problem creating index in 6,5,3 |
Дата | |
Msg-id | 14732.947023218@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] problem creating index in 6,5,3 (Karl DeBisschop <kdebisschop@range.infoplease.com>) |
Ответы |
Re: [BUGS] problem creating index in 6,5,3
|
Список | pgsql-bugs |
Karl DeBisschop <kdebisschop@range.infoplease.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
В списке pgsql-bugs по дате отправления: