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-06 12:38:50 |
Message-ID: | 200412061338.50155.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Tom,
> Because the trigger function is plpgsql, this could happen only the
> first time the trigger is fired in a particular session (unless you are
> using EXECUTE to invoke the update command?). If the problem is related
> to the planner constant-folding environment, then the first-time-only
> limitation would help make it hard to reproduce.
It looks like your suspicion was right.... I've isolated one particulare case,
simply run the script attached. If you remove the comment before the extra
call of spawn_pol() at the bottom of the script, the error is avoided.
Hopefully, solving this will also solve the other cases of mem-alloc error
I've been seeing ;) I'm not using spawn_pol/sol() during the earlier
mentioned conversion, but my hope is that the error generated during
conversion will turn out to be related and caused by the constant-folding of
some other function. But I'll know soon enough if it isn't ;)
Looking forward to your assesment.
--
Best,
Frank.
Attachment | Content-Type | Size |
---|---|---|
tom_demo.sql | text/plain | 6.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PostgreSQL Bugs List | 2004-12-06 13:27:59 | BUG #1341: problem when showing resulted in the screen |
Previous Message | PostgreSQL Bugs List | 2004-12-06 10:44:32 | BUG #1339: enable to init database cluster |