| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Matt Magoffin <postgresql(dot)org(at)msqr(dot)us> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Out of memory on SELECT in 8.3.5 |
| Date: | 2009-02-09 22:13:59 |
| Message-ID: | dcc563d10902091413l5e09368dv22a96d24c9e26a4c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Feb 9, 2009 at 2:40 PM, Matt Magoffin <postgresql(dot)org(at)msqr(dot)us> wrote:
>>> Yes... and indeed changing vm.overcommit_ratio to 80 does allow that
>>> previously-failing query to execute successfully. Do you think this is
>>> also what caused the out-of-memory error we saw today just when a
>>> transaction was initiated?
>>
>> Curious, what's the explain analyze look like for that one?
>
> Do you mean the transaction initiation? I'm not sure how to get an EXPLAIN
> for that, the application never got to do anything, from the application
> side it failed with out-of-memory while trying to open the connection. Or,
> the most precise I have is that in the JDBC driver, it failed at
No, explain analyze for the query that wouldn't execute before but now
does, with, I assume, a large work_mem. I'd like to see how it
differes from the one with smaller work_mem.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Yen | 2009-02-09 22:17:59 | trying to make sense of deadlocks |
| Previous Message | SHARMILA JOTHIRAJAH | 2009-02-09 21:46:34 | ora2pg or dbi_link ? |