Re: Assertion failure with assignment to array elem

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