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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Casey Duncan
Дата:
Сообщение: Re: Two efficiency questions - clustering and ints
Следующее
От: Ron Johnson
Дата:
Сообщение: Re: Storing images in PostgreSQL databases (again)