Jim Mlodgenski <jimmy76@gmail.com> writes:
> I have an extension[1] that adds a collection data type using the expanded
> object API. Things perform well as it gets passed around inside a plpgsql
> function, but when passing it as an INOUT parameter, I'm hitting a double
> free.
You really need to show us your C code. I tried this variant of
your test case:
CREATE PROCEDURE prc(INOUT c int[], i int, j int)
AS $$
BEGIN
c[i] := j;
END;
$$ LANGUAGE plpgsql;
DO $$
DECLARE
c int[];
BEGIN
FOR i IN 1..10 LOOP
CALL prc(c, i, i+10);
END LOOP;
RAISE NOTICE 'c = %', c;
END;
$$;
and got what I expected:
NOTICE: c = {11,12,13,14,15,16,17,18,19,20}
Tracing suggests that the expanded array object created by the
subscript assignment is getting flattened on the way out of the
procedure in order to stuff it into the composite value that is the
procedure's actual result. So that's pretty sad from a performance
standpoint: it means we aren't getting any real benefit from the
INOUT variable. But it also means that there's not any sharing of
expanded-object state between the procedure and its caller, so
it's not apparent to me that this example should be bug-prone.
In any case, the lack of failure for an array seems to me to let
plpgsql off the hook. There's something in your extension that's
not doing what's expected.
regards, tom lane
