Thanks for your reply.
I was expecting not much more than 50 rows to be returned, with an absolute
maximum of 70.
I was trying to simulate an outer join by using the "where not exists"
clause, so that I would get back my full list of 70 and be able to see the
unmatched entries...
-Original Message-
From: Tom Lane [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, May 09, 2000 12:35 PM
To: Jeff Eckermann
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Query bombed: why?
Jeff Eckermann [EMAIL PROTECTED] writes:
After about 25 minutes of running a query with a "where not exists
'correlated subquery'", I got a whole bunch of lines printing out:
"Backend
sent D message without prior T".
Could someone give me an idea of what that means, and how to deal with
it?
How many rows were you expecting the query to produce? (It might be
worth redoing it as a SELECT count(*) FROM ... to find out how many it
really produced.) My first bet is that your frontend application ran
out of memory while trying to absorb the query result. libpq is
designed to collect the whole result before handing it back to the
application, which is nice for some things but starts to look like a bad
idea when you have a huge query result. Also, libpq doesn't react very
gracefully to running out of memory :-( --- the symptoms you describe
sound like one likely failure mode. (We need to fix that...)
You might be able to increase your process memory limit; otherwise,
consider using DECLARE CURSOR and FETCH to retrieve the query result
a few hundred rows at a time.
regards, tom lane
