Skip site navigation (1) Skip section navigation (2)

Re: Assertion failure with assignment to array elem

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Assertion failure with assignment to array elem
Date: 2010-08-09 16:51:21
Message-ID: 4C603209.3070107@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On 09/08/10 19:32, Tom Lane wrote:
> I wrote:
>> Yeah, I don't like that either.  What we need to do instead is fix
>> exec_assign_value so that it can cope with the case of the caller having
>> an open expression evaluation.  We can easily have it save/restore
>> eval_tuptable.  Not resetting eval_econtext is a bit harder, but maybe
>> we could have a use-count variable ... or even easier, just decree that
>> the caller has to do exec_eval_cleanup after calling exec_assign_value,
>> whether or not it had an open expression eval.
>
> After a bit of experimentation, I propose the attached patch.  I don't
> think any additional resets of eval_econtext are necessary.  There are
> some callers of exec_assign_value that don't immediately do an
> exec_eval_cleanup afterwards, but one will happen soon enough.

Ok, I was just trying to figure out that part too, but that works for me.

There's a related issue:

CREATE OR REPLACE FUNCTION dummy() RETURNS integer AS $$ SELECT 
NULL::integer; $$ LANGUAGE sql;

postgres=# do $$
declare
   i integer NOT NULL := 1;
begin
   i := COALESCE(dummy(), (SELECT NULL::integer));
exception
   WHEN OTHERS THEN BEGIN
     i := COALESCE(dummy(), (SELECT 3::integer));
     raise notice 'bar';
   END;
end;
$$;
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

The assertion failure is the same. In this case, when we ereport() at 
the first assignment (because it tries to assign NULL to a variable that 
is declared as NOT NULL), estate->eval_tuptable is not cleaned up. The 
2nd assignment traps the same assertion.

This one is simple to fix, we can always call exec_eval_cleanup() before 
running the exception handler:

--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -1092,6 +1092,8 @@ exec_stmt_block(PLpgSQL_execstate *estate, 
PLpgSQL_stmt_block *block)
                         /* Revert to outer eval_econtext */
                         estate->eval_econtext = old_eval_econtext;

+                       exec_eval_cleanup(estate);
+
                         /*
                          * If AtEOSubXact_SPI() popped any SPI context 
of the subxact, it
                          * will have left us in a disconnected state. 
We need this hack

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-08-09 16:54:58
Subject: Re: Assertion failure with assignment to array elem
Previous:From: Tom LaneDate: 2010-08-09 16:32:04
Subject: Re: Assertion failure with assignment to array elem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group