From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "John Cheng" <chonger(dot)cheng(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: What to do after an "ERROR: out of memory" |
Date: | 2008-07-29 15:42:41 |
Message-ID: | 11380.1217346161@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"John Cheng" <chonger(dot)cheng(at)gmail(dot)com> writes:
> We were updating a large set of data (executing a stored procedure
> against a large set of data in one statement/transaction) while
> autovacuum was running.
> The resulting message looked like:
> 2008-07-28 21:18:08 CDT CONTEXT: automatic vacuum of table
> "databasename._lms.sl_log_2" TopMemoryContext: 154528 total in 18
> blocks; 19104 free (62 chunks); 135424 used
> ....
> 2008-07-28 21:28:53 CDT database_other ERROR: out of memory
> 2008-07-28 21:48:13 CDT ERROR:
> canceling autovacuum task
> ...
Given the time delays there, I don't think the out-of-memory in the
update had anything to do with the autovacuum cancel. Evidently
something sent the autovac process a SIGINT, but it wasn't as a result
of the memory issue. Perhaps someone just mis-aimed a pg_cancel_backend
call?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-29 15:52:01 | Re: interesting trigger behaviour in 8.3 |
Previous Message | Csaba Nagy | 2008-07-29 15:33:22 | Re: interesting trigger behaviour in 8.3 |