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.
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 |