On Tue, Dec 15, 2015 at 8:41 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: >> PG code usually avoids that, and I recall static analyze tools type >> coverity complaining that this may lead to undefined behavior. While I >> agree that this would lead to NaN... > > > Hmmm. In this case that is what is actually wanted. If there is no > transaction, the tps or average latency or whatever is "NaN", I cannot help > it, and IEEE 754 allow that. So in this case the tool is wrong if it > complains, or at least we are right to ignore the warning. Maybe there is > some special comment to say "ignore this warning on the next line" if it > occurs, if this is an issue.
Yeah, that's actually fine. I just had a look at Windows stuff, and things seem to be correct on this side for double: https://msdn.microsoft.com/en-us/library/aa691373%28v=vs.71%29.aspx And then I also had a look at src/port/snprintf.c, where things get actually weird when no transactions are run for a script (emulated with 2 scripts, one with @10000 and the second with @1): - 0 transactions (0.0% of total, tps = 0.000000) - latency average = -1.#IO ms - latency stddev = -1.#IO ms And it seems that this is a bug in fmtfloat() because it does not handle nan values correctly. Others, any thoughts about that? It is possible to address things within your patch by using isnan() and print another message but I think that we had better patch snprintf.c if my analysis is right. Oh, and actually when trying to compile the patch on Windows things are failing because int64_t is undefined :) After switching to int64 things worked better. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
