From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: partition table and stddev() /variance() behaviour |
Date: | 2018-06-21 14:01:46 |
Message-ID: | 26541.1529589706@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-06-21 14:14:54 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Konstantin Knizhnik | 2018-06-21 14:01:09 | Re: WAL prefetch |