Re: [HACKERS] Another nasty cache problem - Mailing list pgsql-hackers

From Patrick Welche
Subject Re: [HACKERS] Another nasty cache problem
Date
Msg-id 20000204171153.D3402@quartz.newn.cam.ac.uk
Whole thread Raw
In response to Re: [HACKERS] Another nasty cache problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Another nasty cache problem
List pgsql-hackers
It seems that I am still tracking problems, but each time they turn out to
have a different cause: A slight variant on the select that caused memory
to run out gives


newnham=# select crsids.surname, "tblPerson"."Surname" from crsids,"tblPerson" where
crsids.usn="tblPerson"."USN"::int4;
pqReadData() -- backend closed the channel unexpectedly.       This probably means the backend terminated abnormally
  before or while processing the request.
 
The connection to the server was lost. Attempting reset: Failed.

Nested Loop  (cost=66496.62 rows=34359 width=40) ->  Seq Scan on tblPerson  (cost=157.62 rows=2625 width=24) ->  Seq
Scanon crsids  (cost=25.27 rows=584 width=16)
 

this is the table I based the memory hog on (2600*600). The backend closes
instantly ie., no memory usage! And, as before, it is hard to find a test case
that will do the same as repeatably (ie., test case never crashes, the
above case crashes every single time). "tblPerson", as its strange
capitalisation suggests, was imported from M$ access via ODBC.

select test.txt,test2.var from test,test2 where test2.i=test.var::int4;

Nested Loop  (cost=63504.80 rows=2600 width=40) ->  Seq Scan on test2  (cost=24.80 rows=600 width=16) ->  Seq Scan on
test (cost=105.80 rows=2600 width=24)
 

works fine.

Any thoughts on where to look?

Cheers,

Patrick


pgsql-hackers by date:

Previous
From: Ed Loehr
Date:
Subject: Re: [HACKERS] PC Week Labs benchmark results
Next
From: Marten Feldtmann
Date:
Subject: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL