Dave Page wrote:
> On Mon, Feb 2, 2009 at 8:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Robert Walker" <r(dot)walker(at)mtcworldwide(dot)com> writes:
>>> I have a function that basically loops through a query and uses the results
>>> from that query to do an individual insert into another table, and if there
>>> is a unique violation, it simply raises a notice and continues on. When
>>> trying to debug the function within PgAdminIII 1.8.4, when stepping through
>>> to the point of the RAISE NOTICE statement, it displays the following and
>>> then Windows informs me that postgres.exe has crashed:
>> I suppose this is a bug in the plpgsql debugger; which you'll need to
>> report to EDB. The core postgres project does not maintain that code.
> We've tracked this issue down to what appears to be a pl/pgsql bug -
> after setting state_var->value and errm_var->value to null,
> state_var->isnull and errm_var->isnull are not set correspondingly.
But I wonder, why does plpgsql debugger even try to display those
variables after the exception block? I'm not familiar with the tool; I'm
guessing that it just displays all variables, regardless of scope.
In response to
pgsql-bugs by date
|Next:||From: Denis Afonin||Date: 2009-02-27 10:40:44|
|Subject: BUG #4680: Server crashed if using wrong (mismatch) conversion functions|
|Previous:||From: Bhajesh||Date: 2009-02-27 10:06:13|
|Subject: BUG #4679: invalid UTF-8 byte sequence detected near byte 0xa3 + postgresql|