Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
От | Tom Lane |
---|---|
Тема | Re: "invalid memory alloc request size |
Дата | |
Msg-id | 15107.1102112857@sss.pgh.pa.us обсуждение исходный текст |
Ответ на |
Re: "invalid memory alloc request size |
Ответы |
Re: "invalid memory alloc request size Re: "invalid memory alloc request size |
Список | pgsql-bugs |
Frank van Vugt <ftm.van.vugt@foxi.nl> writes: > 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. What struck me about the traceback you showed is that it involved an attempt by the planner to constant-fold an SQL-language function that was used in the trigger function's query (and was presumably marked IMMUTABLE and had constant arguments in the query). 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. regards, tom lane
В списке pgsql-bugs по дате отправления: