| 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
| 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 |