On Mon, Jun 20, 2005 at 03:44:24PM -0400, Tom Lane wrote:
> I [Tom Lane] wrote:
> > Actually, I would say the bug is exec_assign_value's. There is nothing
> > at all wrong with a function returning one of its input values; for
> > example the smaller/larger functions all do that.
> For that matter, you don't need a function at all:
> regression=# create or replace function copyit(text) returns text as $$
> regression$# declare tmp text;
> regression$# begin
> regression$# tmp := $1;
> regression$# tmp := tmp;
> regression$# return tmp;
> regression$# end$$ language plpgsql stable;
> CREATE FUNCTION
> regression=# select copyit('foo');
> ERROR: out of memory
> DETAIL: Failed on request of size 1065320319.
> CONTEXT: PL/pgSQL function "copyit" line 4 at assignment
> This makes it perfectly clear that the problem is that exec_assign_value
> must copy the given value before it frees the old, just in case they're
> the same. (Hmm, I wonder if we can shortcircuit the whole thing ...)
Anyone working on fixing this? I'd have tried but I didn't want to dive
into exec_assign_value() and exec_cast_value().
Given that this occurs for almost any assignment of the form
"x := any expression with x" it's hard to avoid without rewritting a lot
of basic assignments with "tmp:=x; x:=foo(tmp)" which is ugly.
We can't use memory checking with this and even without memory checking
I don't trust that memory isn't getting spamed in some situations.
After all it's referencing free'd memory.
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2005-07-22 15:45:15|
|Subject: Re: BUG #1723: array_cat() bug when passed empty array |
|Previous:||From: Bruce Momjian||Date: 2005-07-22 14:44:03|
|Subject: Re: abstime bug|