> "Andrew" == Andrew Gierth writes:
Andrew> My inclination is to fix this in the planner rather than the
Andrew> executor; there seems no good reason to actually hash a
Andrew> duplicate column more than once.
I take this back; I don't believe it's possible to eliminate duplicates
in all
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> 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.
Tom> Sounds reasonable --- but would it make sense to introduce some
Tom>
Andrew Gierth writes:
> 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.
Sounds reasonable --- but would it make sense to introduce some
assertions, or other cheap tests, into the executor to
> "Andrew" == Andrew Gierth 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
> "Tom" == Tom Lane 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
Colm McHugh 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-casser
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
