On Wed, Oct 14, 2026 Sho Ito < mailto:[email protected] > 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 <[email protected]> To: "Shubhankar Anand Kulkarni"<[email protected]> Cc: "pgsql-hackers"<[email protected]>, "pgsql-hackers"<[email protected]>, "robertmhaas"<[email protected]>, "guofenglinux"<[email protected]> 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:[email protected] > 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:[email protected] LinkedIn: https://www.linkedin.com/in/sho-ito-0628/ GitHub: https://github.com/sean0628/ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
v2-0002-Add-a-test-module-for-planner-extension-state.patch
Description: Binary data
v2-0001-Don-t-let-flat-copied-planner-structures-share-ex.patch
Description: Binary data
