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

1 files changed, 5 insertions, 3 deletions

diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 72b952056fe..a9a929d12a2 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -2259,7 +2259,8 @@ evalStandardFunc(CState *st,
 		case PGBENCH_RANDOM_ZIPFIAN:
 			{
 				int64		imin,
-							imax;
+							imax,
+							delta;
 
 				Assert(nargs >= 2);
 
@@ -2268,12 +2269,13 @@ evalStandardFunc(CState *st,
 					return false;
 
 				/* check random range */
-				if (imin > imax)
+				if (unlikely(imin > imax))
 				{
 					fprintf(stderr, "empty range given to random\n");
 					return false;
 				}
-				else if (imax - imin < 0 || (imax - imin) + 1 < 0)
+				else if (unlikely(pg_sub_s64_overflow(imax, imin, &delta) ||
+								  pg_add_s64_overflow(delta, 1, &delta)))
 				{
 					/* prevent int overflows in random functions */
 					fprintf(stderr, "random range is too large\n");