Re: pg_repack issues

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: pg_repack issues
Date: 2014-11-12 02:26:23
Message-ID: 8b20bab72ec52ccdfa256be7ec739d41@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Mark Steben wrote:
> ERROR: query failed: ERROR: value "3048471620" is out of
> range for type integer
> DETAIL: query was: SELECT pg_try_advisory_lock($1, $2)
>
> This happens because the oid values of the tables is this database are
> all over 2 GB. Can I get some insight to make pg_repack work in this
> situation?

That was an unfortunate choice they made in having their second (int)
argument be an OID. A quick fix would be to have it use the single (bigint)
form of pg_try_advisory_lock. Something like this (untested):

diff --git a/bin/pg_repack.c b/bin/pg_repack.c
index af510ca..d638164 100644
- --- a/bin/pg_repack.c
+++ b/bin/pg_repack.c
@@ -1520,13 +1520,12 @@ static bool advisory_lock(PGconn *conn, const char *relid)
{
PGresult *res = NULL;
bool ret = false;
- - const char *params[2];
+ const char *params[1];

- - params[0] = REPACK_LOCK_PREFIX_STR;
- - params[1] = relid;
+ params[0] = relid;

- - res = pgut_execute(conn, "SELECT pg_try_advisory_lock($1, $2)",
- - 2, params);
+ res = pgut_execute(conn, "SELECT pg_try_advisory_lock($1)",
+ 1, params);

if (PQresultStatus(res) != PGRES_TUPLES_OK) {
elog(ERROR, "%s", PQerrorMessage(connection));

You also may want to raise this as an official issue here:

https://github.com/reorg/pg_repack/issues

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201411112120
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlRixSsACgkQvJuQZxSWSsjuFwCfRvWEMeP3Rnb7F0HuRvIMNKwi
wNwAoPq3Sg6Q64C2tK/FdLdTHBo3zqlm
=DiA9
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message John Scalia 2014-11-12 15:48:22 Performance degradation after loss of one standby
Previous Message Mark Steben 2014-11-11 22:07:20 pg_repack issues