Re: [HACKERS] memory problem again

Tom... this is getting even more weird:

logs=> select distinct confid from timelog199911;
pqReadData() -- backend closed the channel unexpectedly.
[...]

Now this:
logs=> \copy timelog199911 to timelog199911
Successfully copied.
logs=> drop table timelog199911;
DROP
logs=> CREATE TABLE "timelog199911" (       "loginname" text,       "site" character varying(16),       "start_time"
datetime,      "elapsed" timespan,       "port" text,       "valid" bool,       "ipaddress" inet,       "confid" int4,
    "session_id" text);
 
[...]
CREATE
logs=> CREATE  INDEX "timelog199911_loginname_idx" on "timelog199911" using 
btree ( "loginname" "text_ops" );
CREATE
logs=> \copy timelog199911 from timelog199911
(ok, I know it's smarted to build the index after copying in the data)
Successfully copied.

logs=> select distinct confid from timelog199911;
sbrk: grow failed, return = 12
sbrk: grow failed, return = 12
pqReadData() -- backend closed the channel unexpectedly.
[...]

logs=> select confid from timelog199911;
[...]
(208749 rows)

Weird!

Daniel

>>>Tom Lane said:> Daniel Kalchev <daniel@digsys.bg> writes:> > I have this problem with PostgreSQL 6.5.2:> > > logs=>
selectdistinct confid > > logs-> from timelog199910> > logs-> where> > logs-> confid IS NOT NULL;> > pqReadData() --
backendclosed the channel unexpectedly.> > > The logged message in stderr (of postmaster) is > > FATAL 1:  Memory
exhaustedin AllocSetAlloc()> > Odd.  I can't replicate this here.  (I'm using 6.5.3, but I doubt that> matters.)  There
mustbe some factor involved that you haven't told us.> You don't have any triggers or rules on the table, do you?> >
Hasanyone else seen anything like this?> >             regards, tom lane