Re: ERROR: Memory exhausted in AllocSetAlloc(188)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jim(at)nasby(dot)net
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: Memory exhausted in AllocSetAlloc(188)
Date: 2003-05-21 21:03:14
Message-ID: 11909.1053550994@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> On Wed, May 21, 2003 at 04:39:18PM -0400, Tom Lane wrote:
>> Each pending deferred-trigger action takes about 40 bytes + palloc
>> overhead, probably 48 bytes altogether ... 48 * 35M comes to 1.68G, so
>> that's exactly where your problem is. I'd suggest trying to commit the
>> changes in smaller batches ...

> Ugh... would two triggers double that? Where can I get more info on
> what's happening under the covers here, especially on what a deferred
> trigger is?

A deferred trigger is an AFTER trigger. If you can do your work in
BEFORE triggers, you should.

Two triggers firing on the same row action (insert/update/delete) do not
double the memory --- there's one trigger queue entry per action. It
looks like it costs about 8 more bytes for each additional deferred
trigger that needs to be fired on the same row action.

Beyond that, read the code --- it's in backend/commands/trigger.c.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Ayers 2003-05-21 21:16:32 Re: "IN" statement causing execution cancel?
Previous Message Andrew Sullivan 2003-05-21 20:57:21 Re: VACUUM and transaction ID wraparound

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2003-05-21 21:15:21 Re: Removing width from EXPLAIN
Previous Message Andrew Sullivan 2003-05-21 20:52:04 Re: Heads up: 7.3.3 this Wednesday