| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | 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-09-17 02:51:59 |
| Message-ID: | 598915.1789613519@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> Fuzzing with Claude, I ran into an assertion failure that comes from
> commit 2ebf25e7d:
> create table t1 (a int, b int, c int);
> create table t2 (a int primary key, b int, c int);
> select j.x from (t1 s(x) left join t2 on s.x = t2.a) j;
> server closed the connection unexpectedly
Ugh.
> I think this varnosyn is fine to keep. The join is only removed from
> the jointree; its RTE stays in the rangetable through to the final
> plan, so varnosyn still names a valid RTE. And join removal didn't
> touch varnosyn before 2ebf25e7d either.
True.
> Attached is a fix.
The main consumer of varnosyn is ruleutils.c, so I don't like
the fact that this test case isn't showing what ruleutils will
do with the Var. If we make it be "explain verbose", do we
get a display of the problematic Var?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2026-09-17 02:59:58 | Re: Distinguish publication exclusions in object addresses |
| Previous Message | Sami Imseih | 2026-09-17 02:50:26 | Re: Reject WAIT FOR earlier in transaction-snapshot mode |