Re: [HACKERS] Another nasty cache problem
От | Patrick Welche |
---|---|
Тема | Re: [HACKERS] Another nasty cache problem |
Дата | |
Msg-id | 20000204171153.D3402@quartz.newn.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] Another nasty cache problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Another nasty cache problem
|
Список | 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 по дате отправления: