ERROR: query failed: ERROR: unexpected index definition

[nezda]

When I tried to repack my bloated table an error occurred:

postgres@db:~$ time /usr/lib/postgresql/9.6/bin/pg_repack -e --table party lexdb
LOG: (query) select repack.version(), repack.version_sql()
LOG: (query) SET statement_timeout = 0
LOG: (query) SET search_path = pg_catalog, pg_temp, public
LOG: (query) SET client_min_messages = warning
LOG: (query) SELECT t.*, coalesce(v.tablespace, t.tablespace_orig) as tablespace_dest FROM repack.tables t,  (VALUES (quote_ident($1::text))) as v (tablespace) WHERE (relid = $2::regclass) ORDER BY t.relname, t.schemaname
LOG: 	(param:0) = (null)
LOG: 	(param:1) = party
INFO: repacking table "party"
LOG: (query) SELECT pg_try_advisory_lock($1, CAST(-2147483648 + $2::bigint AS integer))
LOG: 	(param:0) = 16185446
LOG: 	(param:1) = 2429776
LOG: (query) BEGIN ISOLATION LEVEL READ COMMITTED
LOG: (query) SET LOCAL statement_timeout = 100
LOG: (query) LOCK TABLE party IN ACCESS EXCLUSIVE MODE
LOG: (query) RESET statement_timeout
LOG: (query) SELECT pg_get_indexdef(indexrelid) FROM pg_index WHERE indrelid = $1 AND NOT indisvalid
LOG: 	(param:0) = 2429776
LOG: (query) SELECT indexrelid, repack.repack_indexdef(indexrelid, indrelid, $2, FALSE)  FROM pg_index WHERE indrelid = $1 AND indisvalid
LOG: 	(param:0) = 2429776
LOG: 	(param:1) = (null)
ERROR: query failed: ERROR:  unexpected index definition: CREATE UNIQUE INDEX party_pkey ON public.party USING btree (id) TABLESPACE pg_default
DETAIL: query was: SELECT indexrelid, repack.repack_indexdef(indexrelid, indrelid, $2, FALSE)  FROM pg_index WHERE indrelid = $1 AND indisvalid
LOG: (query) SELECT repack.repack_drop($1, $2)
LOG: 	(param:0) = 2429776
LOG: 	(param:1) = 0

I can reproduce it every time with any table: always produces an `ERROR: unexpected index definition.

PostgreSQL 9.6.8 on x86_64-pc-linux-gnu (Debian 9.6.8-1.pgdg80+1), compiled by gcc (Debian 4.9.2-10+deb8u1) 4.9.2, 64-bit

pg_repack 1.4.2 installed via

sudo pip install pgxnclient
sudo apt-get install postgresql-server-dev-9.6
sudo pgxn install pg_repack
psql -c "CREATE EXTENSION pg_repack" -d lexdb

[akissa]

It is happening on pg 10.3 as well

[akissa]

The issue is caused by the fact that the indexdef in pg_indexes now returns a schema qualified name, which the pg_repack parse_indexdef function is unable to parse correctly.

[akissa]

The following patch fixes the issue for me

diff -ruN pg_repack-1.4.2.orig/lib/repack.c pg_repack-1.4.2/lib/repack.c
--- pg_repack-1.4.2.orig/lib/repack.c   2017-10-13 10:16:37.000000000 +0200
+++ pg_repack-1.4.2/lib/repack.c        2018-03-06 19:52:26.803999938 +0200
@@ -354,11 +354,7 @@
        Oid             nsp = get_rel_namespace(relid);
        char   *nspname;

-       /* Qualify the name if not visible in search path */
-       if (RelationIsVisible(relid))
-               nspname = NULL;
-       else
-               nspname = get_namespace_name(nsp);
+       nspname = get_namespace_name(nsp);

        return quote_qualified_identifier(nspname, get_rel_name(relid));
 }

Not sure if there are any undesirable side effects.

[nezda]

@akissa I used your patch and it seemed to work - thanks for posting it!

[MasahikoSawada]

Thank you for the reporting! I've created a PR #172 to fix this problem.

[justinpryzby]

Not sure anyone will care, but the merged fix uses #ifdef to test the postgres version being compiled against, but should probably instead test the version of the server at runtime. Otherwise pg_repack compiled against pg10.3 won't run against a 10.2 server, for example, beause it expects schema qualification which isn't there (the opposite of the original problem).

[dvarrazzo]

@justinpryzby thank you for pointing it out, we'll check that the fix in place runs with server with the previous behaviour.

[christophervalles]

Will a new release be created for this fix?

[dvarrazzo]

Yes

[kofrezo]

Could you please create a new tag containing this fix so that a new version can be added to http://apt.postgresql.org/pub/repos/apt/pool/main/p/pg-repack/ ?

[christophervalles]

Any updates about when a new tag containing this fix will be created?

[JBromage]

Hi - just found this thread - is there any ETA for Red Hat / Centos please?

[osimar-medeiros]

+1 For ETA for Red Hat / CentOS

[MasahikoSawada]

I think a new release would include #171 (processing security issue) as well. But it's still under the discussion and seems to block the release.

[paunin]

up

[phumpal]

@dvarrazzo @schmiddy any help the community can provide to get the fix tagged and rleased?

If so let please don't hesitate to let we can be of assistance.

[dvarrazzo]

pg_repack 1.4.3 released