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

From Tom Lane
Subject Re: remove_useless_joins vs. bug #19560
Date
Msg-id 1708836.1787974044@sss.pgh.pa.us
Whole thread
In response to Re: remove_useless_joins vs. bug #19560  (Tender Wang <tndrwang@gmail.com>)
Responses Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match
List pgsql-hackers
Tender Wang <tndrwang@gmail.com> writes:
> After 2ebf25e7d70a8, I hit a crash.

Oh, interesting.  What we have here is:

> SELECT
> FROM (SELECT CASE
>                WHEN NULL
>                  THEN sample_1.a
>                ELSE NULL
>              END AS c2
>       FROM ...

What's apparently happening is that we pull up the sub-select,
and eval_const_expressions flattens the CASE to constant-NULL,
so we don't see the reference to sample_1.a and conclude that
sample_1 can be dropped from the query.  But when we do that,
we try to mutate the original copy of the sub-select's tlist
which still contains sample_1.a, and so we hit the Assert
saying we should no longer see any such Vars.

Not immediately sure what to do about that ... I don't think
that dropping the Asserts would fix it, even if that were
a pleasant answer which it's not.  If we allowed the Var
to become a reference to INVALID_VAR, then when we repeat
the eval_const_expressions run later, we're going to have
problems.  IIRC, there are places where eval_const_expressions
looks up Var properties such as null-ness, and that'd fail.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: remove_useless_joins vs. bug #19560
Next
From: Sehrope Sarkuni
Date:
Subject: [PATCH] Speed up pg_waldump TAP test and fix some GitHub CI Windows flakiness