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

On Tue, 21 Oct 2025 at 02:48, Amit Langote <amitlangote09@gmail.com> wrote:
> For the fix, I tried a slightly different approach from your patch.
> Instead of updating the cached entry to always set
> ri_RootResultRelInfo = rootRelInfo on a cache hit, I made
> ExecGetTriggerResultRel() avoid reusing a rootless ResultRelInfo when
> a rooted one is expected. Concretely, I added assertions on the two
> primary lists and tightened the es_trig_target_relations lookup to
> only return an entry when ri_RootResultRelInfo == rootRelInfo or the
> caller’s rootRelInfo is NULL. That prevents the rootless destination
> built for the INSERT on stages -> pipelines from being reused for the
> later UPDATE from builds -> stages.

  foreach(l, estate->es_trig_target_relations)
  {
  rInfo = (ResultRelInfo *) lfirst(l);
- if (RelationGetRelid(rInfo->ri_RelationDesc) == relid)
+ if (RelationGetRelid(rInfo->ri_RelationDesc) == relid &&
+ (rInfo->ri_RootResultRelInfo == rootRelInfo ||
+ rootRelInfo == NULL))

I don't understand the || rootRelInfo == NULL part. This would break
if we first created the ResultRelInfo with a parent then asked for
another one with no parent.

> This seems a bit safer since it keeps cached entries immutable and
> surfaces mismatches via asserts rather than mutating shared state.

I think creating separate ResultRelInfos is probably a safer bet.
That's what I ended up doing in [1] after posting my initial patch
(which was intended to highlight the problem area.)

David

[1] https://github.com/postgres/postgres/compare/master...david-rowley:postgres:fix_resultrelinfo_caching