Fix up commit 4b3347, where I failed to notice that the initial
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.
This commit is contained in:
parent
4b334745a3
commit
6d3c085b22
@ -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) {
|
||||
|
Loading…
x
Reference in New Issue
Block a user