Re: partition table and stddev() /variance() behaviour - Mailing list pgsql-hackers

From Tom Lane
Subject Re: partition table and stddev() /variance() behaviour
Date
Msg-id 26541.1529589706@sss.pgh.pa.us
Whole thread Raw
In response to Re: partition table and stddev() /variance() behaviour  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: partition table and stddev() /variance() behaviour
List pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> Well, that's quite surprising. It appears to be a bug in
> numeric_poly_combine for machines without a working int128 type. The
> parameters in accum_sum_copy are in the incorrect order.

Ouch.

> The very minimal fix is attached, but I'll need to go look at where
> the tests for this have gone.

coverage.postgresql.org shows that numeric_poly_serialize/combine()
aren't exercised at all by the regression tests.  Which is embarrassing
for this case, but I'm a bit leery of trying to insist on 100% coverage.

It might be a plan to insist on buildfarm coverage for anything with
platform-varying code in it, in which case there's at least one
other undertested bit of HAVE_INT128 code in numeric.c.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: WAL prefetch
Next
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)