Re: BUG #17777: An assert failed in nodeWindowAgg.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, xinwen(at)stu(dot)scu(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17777: An assert failed in nodeWindowAgg.c
Date: 2023-02-13 05:30:02
Message-ID: 1020528.1676266202@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Mon, 13 Feb 2023 at 13:46, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> What about find_compatible_agg()? I don't think there's as severe
>> consequences, but it also doesn't seem right as-is.

> This does not seem related to the issue being reported here. It seems
> to me this would only affect the aggregate deduplication logic and
> nothing else.

> For the case you're complaining about, I don't think shifting the
> goalposts randomly in back-branches is a good idea. For the one you
> reported we might upset someone who has come to rely on the aggstate
> deduplication either for performance or for the number of volatile
> function evaluations. I'm not really on board with changing that
> unless someone highlights that it's causing an actual problem.

Yeah. This behavior is at least semi-documented, IIRC. We need to fix
moving-aggregate mode so it's not used when its assumptions don't hold,
because there's no way that that doesn't lead to insane behavior. But
redefining the deduplication rules seems way more likely to break
existing queries than make anybody happy.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2023-02-13 05:43:05 Re: array_agg(DISTINCT) caused a segmentation fault
Previous Message David Rowley 2023-02-13 05:29:46 Re: BUG #17777: An assert failed in nodeWindowAgg.c