| From: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Wrong results from GROUP BY column removal |
| Date: | 2026-11-11 09:17:32 |
| Message-ID: | CAGjGUAL-KfzDZ92ZxG5gkcZomN0OwSZrKS+55P4VP5teC-CbRg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Richard,
Thanks for working on this! The problem analysis is spot-on. In an
outer join scenario, null-extended rows have NULLs not only in the indexed
column but also across other columns of the nullable table. Once those other
columns are removed from GROUP BY, the null-extended rows and the table's
actual NULL row get mistakenly merged into the same group, leading to wrong
query results. This is indeed a subtle bug introduced by commit bd10ec529,
and the fix looks very solid.
Just a very minor thought on the implementation: while nullable_relids is
allocated in the planner context and will be reclaimed anyway, perhaps we
could consider adding a bms_free(nullable_relids) before exiting
remove_useless_groupby_columns(), just to stay consistent with how other
temporary bitmapsets are cleaned up in that function?It is not a big deal at
all, so feel free to ignore it if you prefer keeping it as-is.
Regards
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-11-11 09:17:52 | Re: Crashes on a partition whose concurrent detach never finished |
| Previous Message | shveta malik | 2026-11-11 09:06:19 | Re: Crashes on a partition whose concurrent detach never finished |