From: Tom Lane <tgl@sss.pgh.pa.us>
To: mat@timescale.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15395: Assert failure when using CURRENT OF with inheritance
In-reply-to: <25035.1537726091@sss.pgh.pa.us>
References: <153764171023.14986.280404050547008575@wrigleys.postgresql.org>
 <25035.1537726091@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 23 Sep 2018 14:08:11 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <607.1537733203.1@sss.pgh.pa.us>
Date: Sun, 23 Sep 2018 16:06:43 -0400
Message-ID: <608.1537733203@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I've not tried yet to create an actual test case for the chgParam-based
> failure.  It's definitely possible that that problem is only hypothetical
> at the moment because cursor plans that would satisfy search_plan_tree
> would be too simple to contain any such flags.  But I think we'd better
> add that logic anyway.

After fooling with that for awhile longer, indeed there doesn't seem to
be a way to cause such a failure today.  The closest thing I was able
to find was that an InitPlan's output params could get marked for
recalculation, resulting in chgParam getting set on nodes that reference
the InitPlan.  A cursor query could certainly contain an InitPlan ---
but there doesn't seem to be any code path that would result in forcing
recalculation of one, except with things that couldn't be in a simple
cursor plan, such as NestLoop joins.  Still, it's not real hard to
conceive of future changes that would render this a live issue, so
I still feel that the search_plan_tree change is a good idea.

So, I've added a test case based on your example and pushed the patch.

BTW, I don't understand your report that just removing the Assert made
it work for you.  That would've resulted in returning an invalid TID
to nodeTidscan.c, which AFAICS should've ended up with an ereport about
a bad block number in heap_fetch.

			regards, tom lane