
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 backend terminated 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 


Tue, 14 Dec 1999 14:13:53 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
[6.5.3] FATAL 1:  my bits moved right off the end of the world!
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

Tue, 14 Dec 1999 15:14:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] [6.5.3] FATAL 1: my bits moved right off the end of the
	world!
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 


Tue, 14 Dec 1999 16:52:50 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] [6.5.3] FATAL 1: my bits moved right off the end of
	the world!