Re: Segfault in RI UPDATE CASCADE on partitioned tables with LIKE+ATTACH child (attnum drift)

On Tue, 21 Oct 2025 at 22:12, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> On Tue, Oct 21, 2025 at 2:20 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > I've attached a v4 patch which does #2, adds tests and fixes the
> > outdated header comment in ExecGetTriggerResultRel().
>
> Not sure if you missed it, but I had added tests in v2/v3 mirroring
> Dmitry's case.

I did miss that. You didn't mention it in the email and I didn't look
down far enough to see them.

> In the attached v5, I’ve updated the test case to use the no-op CTE I
> mentioned above, trimmed the test case code a bit, and modified it to
> use a new schema like the surrounding tests. I also updated the
> comment in ExecGetTriggerResultRel() as you did, and moved the
> additional-check explanation into the header comment.

Thanks. The CTE test seems worthwhile since it can reuse the same
tables and results in using the es_opened_result_relations List. I've
included it. I also tidied up the tests a bit more. I looked at your
v5 test case and saw it hadn't gone through the same simplification
process as I put my version through (making tables non-partitioned
when they don't need to be to trigger the issue), so what's in v6 is
my version.

I've attached v6. If you have other proposed changes, would you be
able to send them as a diff based on my patch? We seem to have got
some split-brain and the patches have diverged a little and that
resulted in some of my v4 changes being lost.

I also checked to see if there were any changes around what's shown in
the Triggers portion of EXPLAIN ANALYZE for Dmitry's query. Both
patched and unpatched EXPLAIN ANALYZE are the same. I'm not yet clear
on if it's possible something could be different there now for some
other cases that cause additional ResultRelInfos to be added to the
lists.

David