MIME-Version: 1.0
References: <19470-0a344a5b356fc1a8@postgresql.org>
 <95eeb76a-74eb-46f8-a579-c1aefdad8d8f@app.fastmail.com>
In-Reply-To: <95eeb76a-74eb-46f8-a579-c1aefdad8d8f@app.fastmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Wed, 10 Jun 2026 18:40:52 +0900
Message-ID: 
 <CA+HiwqEoNtf=UAe2vHeCY3cHOgUfrzWJp2PC474KKfd4aGz-uA@mail.gmail.com>
Subject: Re: BUG #19470: PostgreSQL backend aborts (assert failure) when a
 prepared statement returns a composite type cast t
To: Euler Taveira <euler@eulerto.com>
Cc: haogangmao@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BHiwqEoNtf%3DUAe2vHeCY3cHOgUfrzWJp2PC474KKfd4aGz-uA%40mail.gmail.com>
Precedence: bulk

Hi,

On Tue, May 5, 2026 at 11:37=E2=80=AFAM Euler Taveira <euler@eulerto.com> w=
rote:
> On Wed, Apr 29, 2026, at 8:27 AM, PG Bug reporting form wrote:
> >
> > Reproduction steps (minimal):
> >   BEGIN;
> >   CREATE TYPE foo AS (a int, b text);
> >   PREPARE p AS SELECT CAST(ROW(1, 'hello') AS foo)::text;
> >   EXECUTE p;
> >   ALTER TYPE foo ALTER ATTRIBUTE a TYPE VARCHAR(100);
> >   EXECUTE p;
> >   COMMIT;
> >
>
> Thanks for your report! The attached patch fixes this case. I included a
> similar test case but I'm fine if the test is not included with this fix.=
 I
> decided to create a separate function instead of adding the new condition=
s to
> record_plan_type_dependency() because it keeps the fix simple and isolate=
d.
>
> The crash is reproduced back to v11 which means this fix should be backpa=
tched
> to all supported versions.

Thanks for working on this.

I think this is on the right track. Using relationOids is the right
mechanism, since the DDL doesn't touch the composite's pg_type row and
a TYPEOID inval item wouldn't work here. Doing it in fix_expr_common
covers extract_query_dependencies too.

What I'm less easy about is whether Const and RowExpr are the only
carriers. As written, the TYPTYPE_COMPOSITE test won't look through an
array over a composite or a domain over one, and nodes like
FieldSelect and ConvertRowtypeExpr also carry composite type OIDs.
Could you check whether any of those reproduce a similar crash? If so
we'd want to look through to the element/base type and/or cover more
node types before this goes in.

Modulo that, I'll prepare to push to all supported branches.

--=20
Thanks, Amit Langote