From: David Geier <david@swarm64.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault
Date: Tue, 19 Jan 2021 08:41:20 +0100
Message-ID: <00d461cf-c919-6a3e-2dda-c1b5d2207f3d@swarm64.com> (raw)
In-Reply-To: <416507.1611009730@sss.pgh.pa.us>
References: <0253344d-9bdd-11c4-7f0d-d88c02cd7991@swarm64.com>
<347100.1610995608@sss.pgh.pa.us>
<3ad851cf-ce22-ace0-726d-56209e214981@swarm64.com>
<416507.1611009730@sss.pgh.pa.us>
Hi,
On 18.01.21 23:42, Tom Lane wrote:
> David Geier<david@swarm64.com> writes:
>> On 18.01.21 19:46, Tom Lane wrote:
>>> 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.
>> That makes sense. Thanks for the explanation.
> OK, cool. I was afraid you'd argue that you really needed your CustomScan
> node to be transparent in such cases. We could imagine inventing an
> additional custom-scan-provider callback to embed the necessary knowledge,
> but I'd rather not add the complexity until someone has a use-case.
I was thinking about that. Generally, having such possibility would be
very useful. Unfortunately, I believe that in my specific case even
having such functionality wouldn't allow for the query to work with
CURRENT OF, because my CSP behaves similarly to a materialize node.
My understanding is only such plans are supported which consist of nodes
that guarantee that the tuple returned by the plan is the unmodified
tuple a scan leaf node is currently positioned on?
Still, if there's interest I would be happy to draft a patch. Instead of
a separate CSP callback, we could also provide an additional flag like
CUSTOMPATH_SUPPORT_CURRENT_OF. The advantage of the callback would be
that we could delay the decision until execution time where potentially
more information is available.
>> I updated the patch to match your proposal.
> WFM, will push in a bit.
>
> regards, tom lane
Best regards,
David
Swarm64
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: david@swarm64.com, tgl@sss.pgh.pa.us
Subject: Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault
In-Reply-To: <00d461cf-c919-6a3e-2dda-c1b5d2207f3d@swarm64.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox