Re: BUG #19783: Sorted GROUPING SETS return a grouping column's value in a set that leaves it out

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Re: BUG #19783: Sorted GROUPING SETS return a grouping column's value in a set that leaves it out
Date: 2026-10-25 14:03:19
Message-ID: CAJTYsWVxAnsYvcok8GUicWcr4=1quW0uNjEfVgqM1ocRmpU3WQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Thu, 22 Oct 2026 at 11:55, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 19783
> Logged by: Alperen Keles
> Email address: alpkeles99(at)gmail(dot)com
> PostgreSQL version: 19rc1
> Operating system: macOS 26 arm64
> Description:
>
> Hello,
>
> With a sorted grouping-sets plan (GroupAggregate), a column that is not
> in the current grouping set can show its real value instead of NULL,
> while GROUPING() for the same row says it is not grouped. It happens
> when the row has a NULL somewhere and the target list reads a column
> that comes after the grouping columns in the Agg's input:
>
> CREATE TABLE t (id int PRIMARY KEY, a int, b int, c int);
> INSERT INTO t VALUES (1, 10, NULL, 100);
> SET enable_hashagg = off;
> SELECT a, b, c, GROUPING(a, b) AS g
> FROM t GROUP BY GROUPING SETS ((id, a), (id, b));
>
> a | b | c | g
> ----+---+-----+---
> 10 | | 100 | 1
> 10 | | 100 | 2
> (2 rows)
>
> The second row belongs to the set (id, b), so a should be NULL there
> (g = 2 says so). 18.6 and 14.24, and master with enable_hashagg = on,
> give
>
> a | b | c | g
> ----+---+-----+---
> 10 | | 100 | 1
> | | 100 | 2
>
> With b = 20 instead of NULL, or without c in the select list, the
> result is right. The plan is
>
> GroupAggregate
> Output: a, b, c, GROUPING(a, b), id
> Group Key: t.id, t.a
> Sort Key: t.id, t.b
> Group Key: t.id, t.b
> -> Sort
> Output: a, b, id, c
> Sort Key: t.id, t.a
>

Thanks for the report and repro, I could repro it in master.

I think we're losing the NULL set by prepare_projection_slot() when
we fetch c. That deforms the slot again and seems to put a's original
NULL flag back, so we get 10 instead of NULL.

I tried slot_getallattrs() before setting the NULLs and it fixes the
example. But I'm unsure if it will be reasonable here, since it would
increase the cost of fetching columns which are not really required.

ccing David, should we add this to the PG 19 open items?

Regards,
Ayush

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message shihao zhong 2026-10-25 15:05:28 Re: BUG #19794: Assert in btvacuumcleanup() fails when page counted in pages_free twice
Previous Message Nitin Motiani 2026-10-25 12:03:00 Re: BUG #19767: pg_get_viewdef prints ORDER BY (- '3'::int4) as (- 3), which reparses as column position -3