Horton

Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault

Zhihong Yu <zyu@yugabyte.com>

View thread View on postgr.es
From: Zhihong Yu <zyu@yugabyte.com>
To: David Geier <david@swarm64.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-01-18T18:08:32Z
Lists: pgsql-hackers 
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 <david@swarm64.com> 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 a Custom Scan node at the root to do some
> post-processing before returning rows. This plan is referenced by a
> second plan with a Tid Scan which originates from a query of the form
> DELETE FROM foo WHERE CURRENT OF my_cursor;
>
> 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.
>
> I attached a patch. Any thoughts?
>
> Best regards,
> David
> Swarm64
>
>

Commits

  1. Remove faulty support for MergeAppend plan with WHERE CURRENT OF.

  2. Avoid crash with WHERE CURRENT OF and a custom scan plan.