Re: Patch to fix write after end of array in hashed agg initialization

>>>>> "Andrew" == Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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)