Обсуждение: [6.5.3] FATAL 1: my bits moved right off the end of the world!

Поиск
Список
Период
Сортировка

[6.5.3] FATAL 1: my bits moved right off the end of the world!

От
The Hermit Hacker
Дата:
Pretty much reproducable each time, and nothing other then that in the
logs...I can restart the process, let it run and after awhile, it does it
again...

I'm trying to get the UdmSearch program in place to replace ht/Dig, and
this is from the program that is creating the databases:

UdmSearch[47380]: Error: Error: 'pqReadData() -- backend closed the channel unexpectedly.       This probably means the
backendterminated abnormally       before or while processing the request.
 

I have a pg_options file set at:

verbose=2
query
hostlookup
showportnumber
syslog=2


but all that appears to show up is:

StartTransactionCommand
query: INSERT INTO dict (url_id,word,intag) VALUES(1248,'enough',1)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: INSERT INTO dict (url_id,word,intag) VALUES(1248,'information',1)
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: INSERT INTO dict (url_id,word,intag) VALUES(1248,'require',1)
ProcessQuery
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)

None production database right now, so its pretty much open game for
trying things with it...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



Re: [HACKERS] [6.5.3] FATAL 1: my bits moved right off the end of the world!

От
Tom Lane
Дата:
Isn't that what you get after a btree index has gotten corrupted?
(Probably by trying to insert a too-large index entry?)

I thought we'd put in a defense against oversize index entries,
but maybe it hasn't made it to the REL6_5 series...
        regards, tom lane


Re: [HACKERS] [6.5.3] FATAL 1: my bits moved right off the end of the world!

От
The Hermit Hacker
Дата:
On Tue, 14 Dec 1999, Tom Lane wrote:

> Isn't that what you get after a btree index has gotten corrupted?
> (Probably by trying to insert a too-large index entry?)
> 
> I thought we'd put in a defense against oversize index entries,
> but maybe it hasn't made it to the REL6_5 series...

Suggestion on what to check for this?  if it restart the process, it
appears to resume from where it left off, so I'm guessing it isn't in the
application itself...?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org