Re: Wrong results from GROUP BY column removal

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

In response to

Browse pgsql-hackers by date

  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