| From: | "Worky Workerson" <worky(dot)workerson(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: DELETE eats up all memory and crashes box |
| Date: | 2006-10-06 19:00:20 |
| Message-ID: | ce4072df0610061200k54835a59x93e8e0caadba3d83@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 10/6/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Worky Workerson" <worky(dot)workerson(at)gmail(dot)com> writes:
> > When I issue a fairly large DELETE query which has multiple tables
> > with FOREIGN KEY .... CASCADE on them, Postgres eats up *all* the
> > memory on my system and the system crashes.
>
> Well, the memory eating is easy to explain: pending-trigger-event list.
> System crash sounds like a kernel bug or misconfiguration. You might
> want to make sure you have "strict" memory overcommit mode set, else the
> problem might just be an inopportune choice of target by the OOM killer.
You were right ... had my vm.overcommit_memory set to 0 (default).
Now the process gets killed soon after it starts.
Is there any way to tune PG to execute such a query, or am I forced to
forgo the convenience of the "ON DELETE CASCADE" and manually delete
the records with a subselect?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-06 19:05:48 | Re: DELETE eats up all memory and crashes box |
| Previous Message | Casey Duncan | 2006-10-06 18:36:51 | Re: Two efficiency questions - clustering and ints |