From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: cyg0810@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17088: FailedAssertion in prepagg.c
Date: Wed, 07 Jul 2021 22:18:01 +0100
Message-ID: <87a6mxrggq.fsf@news-spur.riddles.org.uk> (raw)
In-Reply-To: <1908212.1625690962@sss.pgh.pa.us>
References: <17088-e33882b387de7f5c@postgresql.org>
<YOWJQTovI//DNe8/@paquier.xyz>
<1908212.1625690962@sss.pgh.pa.us>
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: andrew@tao11.riddles.org.uk, tgl@sss.pgh.pa.us, michael@paquier.xyz, cyg0810@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17088: FailedAssertion in prepagg.c
In-Reply-To: <87a6mxrggq.fsf@news-spur.riddles.org.uk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox