Hi,

I have found a bug that is very easy to reprouduce here:

The table is created with this code:

create table DIAGNOSE (ART varchar(1) NOT NULL, AUFENTHALTNR int NOT NULL,  
CREATION_DATE datetime, CREATION_USER varchar(30), DAUERDIAGNOSENR int NOT  
NULL, MODIFICATION_DATE datetime, MODIFICATION_USER varchar(30), NR int NOT  
NULL, OPNR int, TEXT varchar(250) NOT NULL, VERWEILDAUER int, ZEIT datetime);

CREATE UNIQUE INDEX DIAGNOSE_NR ON DIAGNOSE (NR);

Then create a file that contains 100 000 times this line and save it as  
/tmp/DBTEST.sql:

INSERT INTO  DIAGNOSE (CREATION_DATE, CREATION_USER, VERWEILDAUER, ART,  
TEXT, AUFENTHALTNR, NR, OPNR, DAUERDIAGNOSENR, MODIFICATION_USER,  
MODIFICATION_DATE, ZEIT)  VALUES  ('Fri May 07 21:10:52 1999 CEST', 'USER',  
NULL, 'X', 'Noch nicht eingegeben', 71108, 316707, NULL, 0, 'USER', 'Fri May  
07 21:10:52 1999 CEST', 'Fri May 07 21:10:52 1999 CEST');


Then do

psql -q -f /tmp/DBTEST.sql mydb

Wait.

The error messages are ok. But not the closing of the backend!

Is this bug known? Are there any patches out? I use postgresql-6.4.2 on NetBSD.

NOTE: I have only subscribed pgsql-ports@postgreSQL.org

---
   _  _
 _(_)(_)_  David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG,
  _/  \_   Fax +49 33056 82835 NeXTmail dave@turbocat.de
 (______)  http://www.turbocat.de/
           DEVELOPMENT * CONSULTING * ADMINISTRATION

Wed, 12 May 99 02:37:16 +0200
David Wetzel <dave@turbocat.de>
backend closed the channel unexpectedly
David Wetzel <dave@turbocat.de> writes:
> I have found a bug that is very easy to reprouduce here:

> [ backend crash after many attempts to insert same data into a
> uniquely-indexed table ]

This may be the same bug that was discussed earlier today on the hackers
list: the backend fails to release temporary memory after an error, so
if you make it generate enough error messages during one session you can
eventually run out of memory.  Watch the process with 'top' or some such
to see if it gets up to your system's limit on process size just before
failing.

I'm hoping to look into the cause of the memory leak shortly, but
no guarantees about how soon it might be fixed ;-).

			regards, tom lane

Wed, 12 May 1999 19:15:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] backend closed the channel unexpectedly 
> From: Tom Lane <tgl@sss.pgh.pa.us>
> Sender: owner-pgsql-ports@postgreSQL.org
>
> David Wetzel <dave@turbocat.de> writes:
> > I have found a bug that is very easy to reprouduce here:
>
> > [ backend crash after many attempts to insert same data into a
> > uniquely-indexed table ]
>
> This may be the same bug that was discussed earlier today on the hackers

I cc'ed the mail to pgsql-hackers@postgreSQL.org, pgsql-ports@postgreSQL.org  
But I only subscribe to pgsql-ports@postgreSQL.org.

(...)
> I'm hoping to look into the cause of the memory leak shortly, but
> no guarantees about how soon it might be fixed ;-).
>
> 			regards, tom lane

Great. What we did as bugfix in our importer program is to close and reopen  
the connection to the backend each 1000 rows. This is very ugly but seems to  
work until someone with the backend-knowlege has fixed the bug.

First we thought that we made a mistake in our EOAdaptor*) for PSQL and  
debugged that beast for many hours...

Dave

*) For EOF and WebObjects from Apple/NeXT see www.turbocat.de
   _  _
 _(_)(_)_  David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG,
  _/  \_   Fax +49 33056 82835 NeXTmail dave@turbocat.de
 (______)  http://www.turbocat.de/
           DEVELOPMENT * CONSULTING * ADMINISTRATION

Thu, 13 May 99 01:41:29 +0200
David Wetzel <dave@turbocat.de>
Re: [PORTS] Re: [HACKERS] backend closed the channel unexpectedly 