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(at)digsys(dot)bg> writes:
> > I have this problem with PostgreSQL 6.5.2:
>
> > logs=> select distinct confid
> > logs-> from timelog199910
> > logs-> where
> > logs-> confid IS NOT NULL;
> > pqReadData() -- backend closed the channel unexpectedly.
>
> > The logged message in stderr (of postmaster) is
> > FATAL 1: Memory exhausted in AllocSetAlloc()
>
> Odd. I can't replicate this here. (I'm using 6.5.3, but I doubt that
> matters.) There must be some factor involved that you haven't told us.
> You don't have any triggers or rules on the table, do you?
>
> Has anyone else seen anything like this?
>
> regards, tom lane