>>>>> "Andrew" == Andrew Gierth <and...@tao11.riddles.org.uk> writes:
>>> Attached is a patch for a write after allocated memory which we >>> found in testing. Its an obscure case but can happen if the same >>> column is used in different grouping keys, as in the example below, >>> which uses tables from the regress test suite (build with >>> --enable-cassert in order to turn on memory warnings). Patch is >>> against master. Andrew> I'll look into it. OK, so my first impression is that this is down to (a) the fact that when planning a GROUP BY, we eliminate duplicate grouping keys; (b) due to (a), the executor code isn't expecting to have to deal with duplicates, but (c) when using a HashAgg to implement a Unique path, the planner code isn't making any attempt to eliminate duplicates so they get through. It was wrong before commit b5635948, looks like Andres' fc4b3dea2 which introduced the arrays and the concept of narrowing the stored tuples is the actual culprit. But I'll deal with fixing it anyway unless Andres has a burning desire to step in. My inclination is to fix this in the planner rather than the executor; there seems no good reason to actually hash a duplicate column more than once. -- Andrew (irc:RhodiumToad)