| From: | Jim Mlodgenski <jimmy76(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | INOUT params with expanded objects |
| Date: | 2025-12-10 18:39:06 |
| Message-ID: | CAB_5SRdQS2YpAfJq9agpPP6Zmj7D4JUWdHKeawJ5RqBMDWd5kg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. It looks like the object gets transferred to the context of the
procedure which is freed on completion, but still referenced in the calling
function. There certainly can be something in my extension code, but I found
that the attached patch to exec_assign_value does solve the issue. It's likely
not the right solution with taking a sledge hammer to flatten the object but
it's pointing me to think the issue can be on the plpgsql side. Does anyone
have any ideas I can try on the extension side or better way to solve it on
the plpgsql side?
CREATE PROCEDURE prc(INOUT c collection)
AS $$
BEGIN
c := add(c, 'A', 1::int4);
END;
$$ LANGUAGE plpgsql;
DO $$
DECLARE
c collection('int4');
BEGIN
FOR i IN 1..2 LOOP
CALL prc(c);
END LOOP;
END;
$$;
ERROR: pfree called with invalid pointer 0x56424d513148 (header
0x7f7f7f7f7f7f7f7f)
CONTEXT: PL/pgSQL function inline_code_block line 6 at CALL
-- Jim
| Attachment | Content-Type | Size |
|---|---|---|
| inout_expanded_objects.patch | application/octet-stream | 953 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-12-10 18:40:03 | Re: Returning nbtree posting list TIDs in DESC order during backwards scans |
| Previous Message | Tristan Partin | 2025-12-10 18:37:02 | Re: AIX support |