On 10/6/06, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
"Worky Workerson" <worky.workerson@xxxxxxxxx> 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?
