Re: remove_useless_joins vs. bug #19560

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tender Wang <tndrwang(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: remove_useless_joins vs. bug #19560
Date: 2026-08-29 03:27:24
Message-ID: 1708836.1787974044@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tender Wang <tndrwang(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sehrope Sarkuni 2026-08-29 03:43:54 [PATCH] Speed up pg_waldump TAP test and fix some GitHub CI Windows flakiness
Previous Message Tender Wang 2026-08-29 03:03:49 Re: remove_useless_joins vs. bug #19560