I wrote:
> Now that I look at this, I strongly wonder whether whoever added
> MergeAppend support here understood what they were doing. That
> looks broken, because child nodes will typically be positioned on
> tuples, whether or not the current top-level output came from them.
> So I fear we coul
David Geier writes:
> On 18.01.21 23:42, Tom Lane wrote:
>> 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 ra
Hi,
On 18.01.21 23:42, Tom Lane wrote:
David Geier 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 proc
David Geier 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
Hi,
On 18.01.21 19:46, Tom Lane wrote:
David Geier 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. CustomSc
Zhihong Yu writes:
> I was thinking that, if sstate->ss_currentRelation is null for the other
> cases, that would be a bug.
> An assertion can be added for the cases ending with T_TidScanState.
Maybe, but there are surely a lot of other places that would crash
in such a case --- places far more o
Hi, Tom:
I was thinking that, if sstate->ss_currentRelation is null for the other
cases, that would be a bug.
An assertion can be added for the cases ending with T_TidScanState.
Though, the null sstate->ss_currentRelation would surface immediately
(apart from assertion). So I omitted the assertion
Zhihong Yu writes:
> It seems sstate->ss_currentRelation being null can only
> occur for T_ForeignScanState and T_CustomScanState.
> What about the following change ?
Seems like more code for no very good reason.
regards, tom lane
Hi,
It seems sstate->ss_currentRelation being null can only
occur for T_ForeignScanState and T_CustomScanState.
What about the following change ?
Cheers
diff --git a/src/backend/executor/execCurrent.c
b/src/backend/executor/execCurrent.c
index 0852bb9cec..56e31951d1 100644
--- a/src/backend/exec
David Geier 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 a
Hi,
+* Custom scan nodes can be leaf nodes or inner nodes and
therfore need special treatment.
The special treatment applies to inner nodes. The above should be better
phrased to clarify.
Cheers
On Mon, Jan 18, 2021 at 2:43 AM David Geier wrote:
> Hi hackers,
>
> While working wit
On Mon, Jan 18, 2021 at 4:13 PM David Geier wrote:
>
> Hi hackers,
>
> While working with cursors that reference plans with CustomScanStates
> nodes, I encountered a segfault which originates from
> search_plan_tree(). The query plan is the result of a simple SELECT
> statement into which I inject
12 matches
Mail list logo
