Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running
Date: 2004-12-03 23:01:58
Message-ID: 200412040001.58646.ftm.van.vugt@foxi.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> > The only thing I can think of is that the handling of pol X and creation
> > of pol Y from within spawn_pol() is somehow messing things up, but......

> Certainly the mere firing of a deferred trigger isn't the problem; we do
> that all the time.

Me too ;)

I was more trying to emphase the multiple select for update from both in- as
well as outside the functions, but you'd probably have caught that already if
it could have been the culprit.

> What struck me about the traceback <cut>
> Because the trigger function is plpgsql, this could happen only the
> first time the trigger is fired in a particular session

I've tried to run all immutable functions used at least once before running
the query-set, this made no difference, same error on the same location.

> (unless you are using EXECUTE to invoke the update command?)

No, no, it's a plain call.

--
Best,

Frank.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Marc G. Fournier 2004-12-04 04:18:03 PostgreSQL 8.0.0 Release Candidate 1
Previous Message Tom Lane 2004-12-03 22:27:37 Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running