Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault - Mailing list pgsql-hackers

From Tom Lane
Subject Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault
Date
Msg-id 347100.1610995608@sss.pgh.pa.us
Whole thread Raw
In response to search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault  (David Geier <david@swarm64.com>)
Responses Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault  (Zhihong Yu <zyu@yugabyte.com>)
Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault  (David Geier <david@swarm64.com>)
List pgsql-hackers
David Geier <david@swarm64.com> writes:
> search_plan_tree() assumes that 
> CustomScanState::ScanState::ss_currentRelation is never NULL. In my 
> understanding that only holds for CustomScanState nodes which are at the 
> bottom of the plan and actually read from a relation. CustomScanState 
> nodes which are not at the bottom don't have ss_currentRelation set. I 
> believe for such nodes, instead search_plan_tree() should recurse into 
> CustomScanState::custom_ps.

Hm.  I agree that we shouldn't simply assume that ss_currentRelation
isn't null.  However, we cannot make search_plan_tree() descend
through non-leaf CustomScan nodes, because we don't know what processing
is involved there.  We need to find a scan that is guaranteed to return
rows that are one-to-one with the cursor output.  This is why the function
doesn't descend through join or aggregation nodes, and I see no argument
by which we should assume we know more about what a customscan node will
do than we know about those.

So I'm inclined to think a suitable fix is just

-               if (RelationGetRelid(sstate->ss_currentRelation) == table_oid)
+               if (sstate->ss_currentRelation &&
+                   RelationGetRelid(sstate->ss_currentRelation) == table_oid)
                    result = sstate;

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add primary keys to system catalogs
Next
From: Surafel Temesgen
Date:
Subject: Re: WIP: System Versioned Temporal Table