From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Assertion failure with assignment to array elem |
Date: | 2010-08-09 11:42:45 |
Message-ID: | 4C5FE9B5.1070500@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
postgres=# CREATE OR REPLACE FUNCTION f_test() RETURNS VOID AS $$
DECLARE
arr text[];
lr text;
i integer;
BEGIN
i := 1;
SELECT 'foo' INTO lr;
arr[COALESCE(i, (SELECT NULL::integer))] := COALESCE(lr, (SELECT
NULL::text));
END;
$$ LANGUAGE PLPGSQL;
CREATE FUNCTION
postgres=# SELECT f_test();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
TRAP: FailedAssertion("!(estate->eval_tuptable == ((void *)0))", File:
"pl_exec.c", Line: 4264)
This happens when both the array subscript and the expression been
assigned are "non-simple". The purpose of the funny-looking COALESCE
expressions in the above example is to force them to be non-simple.
This bug applies to all supported versions.
The problem is that exec_assign_value() is passed a value that came from
the current 'estate', but when exec_assign_value() evaluates the array
subscript, we don't expect there to already be an open result set in
'estate'.
A simple fix would be to make a copy of the value being assigned in
exec_assign_expr and calling exec_eval_cleanup() before the call to
exec_assign_value(). But I wonder if the performance impact would be too
high - one extra copy isn't that expensive, but it would affect every
single assignment of pass-by-reference variables.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | vshahov | 2010-08-09 14:43:12 | postgres 9.0 beta libpq empty binary array error |
Previous Message | Itagaki Takahiro | 2010-08-09 09:41:12 | BUG #5608: array_agg() consumes too much memory |