Don't depend on -fwrapv semantics in pgbench's random() function.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 28 Jun 2021 16:40:37 +0000 (12:40 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 28 Jun 2021 16:40:37 +0000 (12:40 -0400)
commit203c5aaaba56715168c1e80a45d4929120c9281b
tree80326b62bc24e23b4ad37d4cb905ae58c1228aef
parente1c1c30f635390b6a3ae4993e8cac213a33e6e3f
Don't depend on -fwrapv semantics in pgbench's random() function.

Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion.  This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizing without regard to the -fwrapv
switch.  Presumably that's a gcc bug that will be fixed soon, but
we might as well install cleaner coding here rather than wait.

(This does not address the question of whether we'll ever be able
to get rid of using -fwrapv.  Testing shows that this spot is the
only place where doing so creates visible regression test failures,
but unfortunately that proves very little.)

Back-patch to v12.  The common/int.h functions exist in v11, but
that branch doesn't use them in any client-side code.  I judge
that this case isn't interesting enough in the real world to take
even a small risk of issues from being the first such use.

Tom Lane and Fabien Coelho

Discussion: https://postgr.es/m/73927.1624815543@sss.pgh.pa.us
src/bin/pgbench/pgbench.c