Fix up commit 4b3347, where I failed to notice that the initial

schmiddy · schmiddy · commit 6d3c085b226e · 2014-11-20T17:18:15.000-05:00
problem was really about the OID being interpreted as an integer literal upon input, and overflowing its integer space before even making it into pg_try_advisory_lock(). (We do still need to add -2147483648 to make the result fit into an integer, as 4b3347 does.) Hopefully fixes issue #30, for real this time.
diff --git a/bin/pg_repack.c b/bin/pg_repack.c
@@ -1359,7 +1359,8 @@ repack_one_table(const repack_table *table, const char *orderby)
 	/* Release advisory lock on table. */
 	params[0] = REPACK_LOCK_PREFIX_STR;
 	params[1] = buffer;
-	res = pgut_execute(connection, "SELECT pg_advisory_unlock($1, -2147483648 + $2)",
+
+	res = pgut_execute(connection, "SELECT pg_advisory_unlock($1, CAST(-2147483648 + $2::bigint AS integer))",
 			   2, params);
 	ret = true;
 
@@ -1530,7 +1531,7 @@ static bool advisory_lock(PGconn *conn, const char *relid)
 	 * *unsigned* 4-byte integer. Add -2147483648 to that OID to make
 	 * it fit reliably into signed int space.
 	 */
-	res = pgut_execute(conn, "SELECT pg_try_advisory_lock($1, -2147483648 + $2)",
+	res = pgut_execute(conn, "SELECT pg_try_advisory_lock($1, CAST(-2147483648 + $2::bigint AS integer))",
 			   2, params);
 
 	if (PQresultStatus(res) != PGRES_TUPLES_OK) {
