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 CAHewXN=kWGAXV537mKtSyBYobGdHhYJVDJJMXXZEmmPWE_zaPw@mail.gmail.com
Whole thread
In response to Re: remove_useless_joins vs. bug #19560  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: remove switch statement in vector8_shift_{left,right}
Re: remove_useless_joins vs. bug #19560
List pgsql-hackers
Hi,

Tom Lane <tgl@sss.pgh.pa.us> 于2026年8月28日周五 21:43写道:
>
> Richard Guo <guofenglinux@gmail.com> writes:
> > On Fri, Aug 28, 2026 at 12:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I take your point that the early-exit-for-trivial-jointree path now
> >> fails to set these fields at all, but I'd rather handle that by
> >> adding a couple more lines in that path to fill them in.  Yup, it'd
> >> be duplicate logic, but it seems cleaner that way.
>
> > Fair enough.  I agree that keeping all of this together at the end of
> > query_planner makes it clear that these fields are not valid before
> > then, and that a half-filled set during the restart loop is a hazard.
> > Adding the few lines to the early-exit path sounds good to me.
>
> Cool.
>
> >> Well, yeah, but on that argument we could drop the entire stanza,
> >> because it's just checking that join_is_removable didn't mess up.
> >> Maybe we should?  I've not heard that anybody ever hit those Asserts.
>
> > I think so.
>
> Sold.  I'll make it so and push.  Thanks for reviewing!

After 2ebf25e7d70a8, I hit a crash.

How to reproduce:

1. Run the regression tests.
2. Run the following query against the regression database:
psql (20devel)
Type "help" for help.

postgres=# \c regression
You are now connected to database "regression" as user "ubuntu".
regression=# SELECT
FROM (SELECT CASE
               WHEN NULL
                 THEN sample_1.a
               ELSE NULL
             END AS c2
      FROM public.shoelace_ok AS ref_2
           LEFT JOIN fkpart5.pk31 AS sample_1 ON ref_2.ok_quant =
sample_1.a) AS subq_0
     RIGHT JOIN public.ruletest_tbl2 AS ref_3 ON NULL,
     LATERAL (SELECT subq_0.c2 AS c0,
                     public.logging_agg_nonstrict(ref_4.a) AS c8
              FROM public.test_inh_check AS ref_4) AS subq_3;
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.

The crash was originally found by SQLSmith. I reduced the original large
query to the reproducer above.


--
Thanks,
Tender Wang



pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Routed ON CONFLICT inserts broken by partition-local deferrable unique constraints in 19 and master
Next
From: Tom Lane
Date:
Subject: Re: remove_useless_joins vs. bug #19560