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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Geier <david@swarm64.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-01-18T21:09:20Z
Lists: pgsql-hackers 
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 in the diff.

Cheers

On Mon, Jan 18, 2021 at 12:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Zhihong Yu <zyu@yugabyte.com> 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
>

Commits

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

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