Re: remove_useless_joins vs. bug #19560 - Mailing list pgsql-hackers

From Tender Wang
Subject Re: remove_useless_joins vs. bug #19560
Date
Msg-id CAHewXNk8b0TsSy4dL=CO7FXL2W3WBm0BcdP-zwNJePa-Qj4HzA@mail.gmail.com
Whole thread
In response to Re: remove_useless_joins vs. bug #19560  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hashjoins vs. Bloom filters (yet again)
Re: hashjoins vs. Bloom filters (yet again)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> 于2026年8月31日周一 00:20写道:
>
> Richard Guo <guofenglinux@gmail.com> writes:
> > ... The exception is
> > flatten_join_alias_vars, which descends into every PHV and asserts on
> > SubPlans.  I changed it to leave PHVs of upper levels alone; such a
> > PHV cannot contain join aliases of the level being flattened anyway.
>
> BTW, this comment reminds me strongly of an earlier draft I had,
> which eliminated the assertion failure by just not letting
> ChangeVarNodes recurse into outer-level PHVs, on the grounds that
> we can ignore their contents until they get replaced by Params.
> That didn't seem terribly principled on its own, so I also made
> eval_const_expressions not do anything to outer-level PHVs, but
> then I started to wonder just how far the implications should extend.
> When I realized that a localized fix in extract_lateral_references()
> seemed possible I gave up on that approach.  But maybe it's the way
> to go.  It has the attractive property of removing useless work.
> Attached is as far as I got with the idea before switching to the
> other way.

Thanks for the fix. It fixes the crash I reported earlier.

While testing the patched version, I found another crash with the
following query:

regression=# explain SELECT
FROM public.rtest_vview4 AS ref_0
     LEFT JOIN (fkpart5.pk AS sample_0
                LEFT JOIN pg_catalog.pg_stat_user_functions AS ref_1 ON NULL)
        ON NULL
     INNER JOIN public.skip_wal_skip_rewrite_index AS sample_5 ON
sample_0.a IS NULL,
     LATERAL (SELECT
              WHERE ref_1.schemaname IS NULL) AS subq_1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.


--
Thanks,
Tender Wang



Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: remove_useless_joins vs. bug #19560
Next
From: Amit Kapila
Date:
Subject: Re: [PATCH] Release replication slot on error in SQL-callable slot functions