Re: BUG #17088: FailedAssertion in prepagg.c
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: guofenglinux@gmail.com, andrew@tao11.riddles.org.uk, michael@paquier.xyz,
cyg0810@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-03-21T21:09:54Z
Lists: pgsql-bugs
Attachments
- v2-0001-fix-oversights-in-GroupingFunc-handling.patch (text/x-diff) patch v2-0001
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes: > At Fri, 9 Jul 2021 14:54:02 +0800, Richard Guo <guofenglinux@gmail.com> wrote in >> Update the patch with comments and test cases. > AFAICS the patch looks correct. It works for the first example and > the two from Tom. I don't find other place that has the similar > issue. I'd been expecting Andrew to pick this up, but since he hasn't, I took a look. I concur that the core problem is that GroupingFunc has to be treated almost exactly like Aggref, and here we have a couple of places that didn't get that memo. So it occurred to me to look for other places that special-case Aggref and don't have parallel code for GroupingFunc, and I found several: expression_returns_set_walker This isn't particularly hazardous, since the argument (probably?) can't contain a SRF, but it still seems like it ought to treat the two node types the same. cost_qual_eval_walker It's defaulting to charging the eval costs of the arguments, which is flat wrong. I made it charge one cpu_operator_cost instead. ruleutils.c Various places concerned with whether or not we need parens were making the wrong choice, resulting in excess parens in pretty-printing mode. This is also just cosmetic, but still. This looks good to me now, and I'll set about back-patching. regards, tom lane
Commits
-
Fix assorted missing logic for GroupingFunc nodes.
- dfefe38fbea4 13.7 landed
- 69c88e2fb0aa 12.11 landed
- 5de244196a5b 11.16 landed
- 48b6035f0f72 14.3 landed
- 2afa031ac552 10.21 landed
- 2591ee8ec44d 15.0 landed