Re: [HACKERS] 6.5.0 - Overflow bug in AVG( )

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> For int2/int4, we could bump the accumulator to int8 (certainly faster
> than our numeric implementation?), but there are a very few platforms
> which don't support int8 and we shouldn't break the aggregates for
> them.

Right, that's why I preferred the idea of using float8.

Note that any reasonable floating-point implementation will deliver an
exact result for the sum of integer inputs, up to the point at which the
sum exceeds the number of mantissa bits in a float (2^52 or so in IEEE
float8). After that you start to lose accuracy. Using int8 would give
an exact sum up to 2^63, but if we want to start delivering a fractional
average then float still looks like a better deal...

> Tom, do you think that a hack in the aggregate support code which
> compares the pointer returned to the pointer input, then pfree'ing the
> input area if they differ, would fix the major leakage?

Yeah, that would probably work OK, although you'd have to be careful of
the initial condition --- is the initial value always safely pfreeable?

> We could even have a backend global variable which enables/disables
> the feature to allow performance tuning.

Seems unnecessary.

regards, tom lane