Re: Overflow hazard in pgbench
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Date: 2021-06-27T20:21:46Z
Lists: pgsql-hackers
I wrote: > ... according to the C99 > spec this code is broken, because the compiler is allowed to assume > that signed integer overflow doesn't happen, whereupon the second > if-block is provably unreachable. The failure still represents a gcc > bug, because we're using -fwrapv which should disable that assumption. > However, not all compilers have that switch, so it'd be better to code > this in a spec-compliant way. BTW, for grins I tried building today's HEAD without -fwrapv, using gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC) which is the newest version I have at hand. Not very surprisingly, that reproduced the failure shown on moonjelly. However, after adding the patch I proposed, "make check-world" passed! I was not expecting that result; I supposed we still had lots of lurking assumptions of traditional C overflow handling. I'm not in any hurry to remove -fwrapv, because (a) this result doesn't show that we have no such assumptions, only that they must be lurking in darker, poorly-tested corners, and (b) I'm not aware of any reason to think that removing -fwrapv would provide benefits worth taking any risks for. But we may be closer to being able to do without that switch than I thought. regards, tom lane
Commits
-
Don't depend on -fwrapv semantics in pgbench's random() function.
- 01697e92a460 15.0 landed
- be567deb3ac9 13.4 landed
- 3fd334795e26 12.8 landed
- 203c5aaaba56 14.0 landed