Re: Segfault in RI UPDATE CASCADE on partitioned tables with LIKE+ATTACH child (attnum drift)
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Dmitry Fomin <fomin.list@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-10-20T19:27:47Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix incorrect logic for caching ResultRelInfos for triggers
- 2992b9a07ef0 15.15 landed
- a546964db6fb 16.11 landed
- 0d3074615380 17.7 landed
- a2387c32f2f8 18.1 landed
- 39dcfda2d23a 19 (unreleased) landed
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