Re: INOUT params with expanded objects - Mailing list pgsql-hackers

From Jim Mlodgenski
Subject Re: INOUT params with expanded objects
Date
Msg-id CAB_5SRe96PpOfg0jqm4zvE3c+9PaKtE780KHOfWfrsPxsWPeEQ@mail.gmail.com
Whole thread Raw
In response to Re: INOUT params with expanded objects  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 10, 2025 at 7:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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:
>

The code is here for reference
https://github.com/aws/pgcollection/blob/main/src/collection.c

> 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.
>

Thanks for pulling me up from the rabbit hole. It looks like when things
come as an INOUT, they are RO and the extension is not handling that
properly. Twiddling with that solves my double free issue, but has other
impacts based on my bad assumptions. It does set me on the right path
though for a full fix in the extension.

--Jim



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Visibility bug in tuple lock
Next
From: Sami Imseih
Date:
Subject: Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements