Re: Oversight in reparameterize_path_by_child leading to executor crash - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Oversight in reparameterize_path_by_child leading to executor crash
Date
Msg-id CAMbWs48=THWJ4dUW7K5WdL1mt1U=Uwg2DyK2Xddn2JeqUGMX+w@mail.gmail.com
Whole thread Raw
In response to Re: Oversight in reparameterize_path_by_child leading to executor crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Oversight in reparameterize_path_by_child leading to executor crash
List pgsql-hackers

On Thu, Aug 24, 2023 at 1:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Richard Guo <guofenglinux@gmail.com> writes:
> If we go with the "tablesample scans can't be reparameterized" approach
> in the back branches, I'm a little concerned that what if we find more
> cases in the futrue where we need modify RTEs for reparameterization.
> So I spent some time seeking and have managed to find one: there might
> be lateral references in a scan path's restriction clauses, and
> currently reparameterize_path_by_child fails to adjust them.

Hmm, this seems completely wrong to me.  By definition, such clauses
ought to be join clauses not restriction clauses, so how are we getting
into this state?  IOW, I agree this is clearly buggy but I think the
bug is someplace else.

If the clause contains PHVs that syntactically belong to a rel and
meanwhile have lateral references to other rels, then it may become a
restriction clause with lateral references.  Take the query shown
upthread as an example,

select count(*) from prt1 t1 left join lateral
    (select t1.b as t1b, t2.* from prt2 t2) s
    on t1.a = s.b where s.t1b = s.a;

The clause 's.t1b = s.a' would become 'PHV(t1.b) = t2.a' after we have
pulled up the subquery.  The PHV in it syntactically belongs to 't2' and
laterally refers to 't1'.  So this clause is actually a restriction
clause for rel 't2', and will be put into the baserestrictinfo of t2
rel.  But it also has lateral reference to rel 't1', which we need to
adjust in reparameterize_path_by_child for partitionwise join.

Thanks
Richard

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: pg_stat_get_backend_subxact() and backend IDs?
Next
From: Amit Kapila
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node