Re: DELETE eats up all memory and crashes box
От | Worky Workerson |
---|---|
Тема | Re: DELETE eats up all memory and crashes box |
Дата | |
Msg-id | ce4072df0610061200k54835a59x93e8e0caadba3d83@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DELETE eats up all memory and crashes box (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DELETE eats up all memory and crashes box
|
Список | pgsql-general |
On 10/6/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Worky Workerson" <worky.workerson@gmail.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?
В списке pgsql-general по дате отправления: