Re: BUG #17088: FailedAssertion in prepagg.c

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, cyg0810(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17088: FailedAssertion in prepagg.c
Date: 2021-07-07 21:18:01
Message-ID: 87a6mxrggq.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> An alternative theory is that we should never have done anything
Tom> at all to the argument tree of a GroupingFunc. Since it's not
Tom> supposed to be evaluated, treating it as a target for expression
Tom> preprocessing might be a mistake altogether. I wonder why its
Tom> arguments aren't stored as sortgroupref indexes or the like.

The arguments are stored as sortgrouprefs (the "refs" list) for actual
use; the "args" list is only kept for the benefit of EXPLAIN and
deparsing.

A number of places in the planner have to explicitly avoid recursing
into GroupingFunc->args when walking trees specifically because they are
not evaluated. It looks to me like some places where that should have
been checked for were missed. Looking into it.

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-07-07 21:22:17 Re: BUG #17088: FailedAssertion in prepagg.c
Previous Message Tom Lane 2021-07-07 20:49:22 Re: BUG #17088: FailedAssertion in prepagg.c