Re: PG19: flat-copied RelOptInfos share extension_state with the original rel

On Wed, Oct 14, 2026 Sho Ito < mailto:i(dot)sho(dot)0628(at)gmail(dot)com > wrote:
> I'm okay with the per-site resets for this fix, alongside the existing

> duplicated path resets.

>

> Yes, I believe regression coverage under src/test/modules would be useful.

Hi Sho,

Thanks.  Attached is v2.

v2-0001 is unchanged from v1 apart from its commit message, which now

carries the usual Author, Reviewed-by and Discussion lines.

v2-0002 adds src/test/modules/test_extendplan.  The module stores a tag in

the extension state of every base and join rel as the planner builds it

(build_simple_rel_hook, joinrel_setup_hook), recording which RelOptInfo

it was stored in.  join_path_setup_hook then checks the joinrel and both

input rels, and emits a WARNING if any of them holds a tag stored in a

different RelOptInfo.  The test plans an eager-aggregation query and an

IN semijoin.  test_extendplan_summary() also reports whether a grouped

rel and a unique-ified rel were actually checked, so the test can't

pass vacuously if the planner stops building those rels for these

queries.

With 0001 and 0002 the test passes.  With 0002 alone it fails:

+WARNING:  extension state of grouped joinrel (b 1 2) belongs to a different RelOptInfo

+WARNING:  extension state of grouped inner rel (b 2) belongs to a different RelOptInfo

...

+WARNING:  extension state of inner rel (b 3) belongs to a different RelOptInfo

+WARNING:  extension state of outer rel (b 3) belongs to a different RelOptInfo

That covers build_grouped_rel(), for both base and join rels, and

create_unique_paths().  The copies made in create_partial_unique_paths()

and build_minmax_path() never reach an extension hook, so the test

can't see them; 0001 resets them for consistency.

The test checks which rel a tag belongs to rather than provoking the

use-after-free.  Whether reading the freed array crashes depends on the

build: with assertions enabled the freed memory is clobbered and the

backend crashes, but without them the stale pointer is usually still

there and the lookup appears to work.  A crash-based test would

therefore not fail reliably without 0001, whereas the ownership check

fails on every build.

>  I'll hold off on updating the status until I've reviewed the

revised patch and run the new test.

Once you verify the test behaviour and it satisfies the need, we can update the patch status accordingly.

Regards,

Shubhankar K.

Member Technical Staff

Zoho Corporation

From: Sho Ito <i(dot)sho(dot)0628(at)gmail(dot)com>
To: "Shubhankar Anand Kulkarni"<shubhankar(dot)ak(at)zohocorp(dot)com>
Cc: "pgsql-hackers"<pgsql-hackers(at)lists(dot)postgresql(dot)org>, "pgsql-hackers"<pgsql-hackers(at)postgresql(dot)org>, "robertmhaas"<robertmhaas(at)gmail(dot)com>, "guofenglinux"<guofenglinux(at)gmail(dot)com>
Date: Wed, 14 Oct 2026 09:02:06 +0530
Subject: Re: PG19: flat-copied RelOptInfos share extension_state with the original rel

On Tue, Oct 13, 2026 at 6:37 AM Shubhankar Anand Kulkarni < mailto:shubhankar(dot)ak(at)zohocorp(dot)com > wrote:

Since this touches both the extension-state API and

eager aggregation, are you OK with resetting the fields at each copy

site, or would you rather have a shared helper that does the flat copy

and the resets in one place? 

I'm okay with the per-site resets for this fix, alongside the existing
duplicated path resets.

 

Also can we turn the reproducer into a src/test/modules test if you'd like regression coverage for it?

Yes, I believe regression coverage under src/test/modules would be useful.

I'll hold off on updating the status until I've reviewed the

revised patch and run the new test.

Thanks,

Sho Ito

--

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Sho Ito (Sean)

E-mail:  mailto:i(dot)sho(dot)0628(at)gmail(dot)com

LinkedIn:  https://www.linkedin.com/in/sho-ito-0628/

GitHub:  https://github.com/sean0628/

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝