RE: Query bombed: why?
От | Jeff Eckermann |
---|---|
Тема | RE: Query bombed: why? |
Дата | |
Msg-id | 79103FDEF940D2118D9D00A0C9C9309CA362F6@NEZU обсуждение исходный текст |
Ответ на | Query bombed: why? (Jeff Eckermann <jeckermann@verio.net>) |
Ответы |
Re: Query bombed: why?
|
Список | pgsql-general |
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:tgl@sss.pgh.pa.us] > Sent: Tuesday, May 09, 2000 12:35 PM > To: Jeff Eckermann > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Query bombed: why? > > Jeff Eckermann <jeckermann@verio.net> 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
В списке pgsql-general по дате отправления: