Re: BUG #1723: array_cat() bug when passed empty array

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Chapeskie <dchapeskie(at)sandvine(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1723: array_cat() bug when passed empty array
Date: 2005-07-22 15:45:15
Message-ID: 106.1122047115@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Dave Chapeskie <dchapeskie(at)sandvine(dot)com> writes:
> On Mon, Jun 20, 2005 at 03:44:24PM -0400, Tom Lane wrote:
>> 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().

Done some time ago, I think [ digs in CVS log... ] yeah, here it is:

2005-06-20 16:44 tgl

* src/pl/plpgsql/src/: pl_exec.c (REL7_3_STABLE), pl_exec.c
(REL7_4_STABLE), pl_exec.c (REL7_2_STABLE), pl_exec.c
(REL8_0_STABLE), pl_exec.c: plpgsql's exec_assign_value() freed the
old value of a variable before copying/converting the new value,
which meant that it failed badly on "var := var" if var is of
pass-by-reference type. Fix this and a similar hazard in
exec_move_row(); not sure that the latter can manifest before 8.0,
but patch it all the way back anyway. Per report from Dave
Chapeskie.

You can get the patches from our CVS server.
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2005-07-22 16:44:31 Re: abstime bug
Previous Message Dave Chapeskie 2005-07-22 15:41:04 Re: BUG #1723: array_cat() bug when passed empty array