Concurrent activity on the target table can cause deadlocks when
repack_drop() is doing its job, ie, dropping the temporary objects
created. It is highly likely to occur when pg_repack is interrupted
midway through its processing.
By commit 7b1c2a0f2066672b24f6257ec9b8d78a1754f494 in PostgreSQL,
builtins.h is splitted to a new header file ruleutils.h.
The usage of pg_get_indexdef_string in lib/repack.c is affected.
Control symbol visibility for functions exported in the pg_repack
shared library, to avoid symbol conflicts with other libraries,
particularly those which may be loaded via shared_preload_libraries
and use conflicting function definitions of our common pgut code,
such as pg_statsinfo.
Verified this fix on my Debian x86_64 machine with PostgreSQL 9.4 and
pg_statsinfo 3.0.2. Would be nice to test this fix on a few other
platforms such as OS X, though I had some difficulty getting
pg_statsinfo to build on OS X. Hopefully closes Issue #43, thanks
to bwtakacy for the report and demonstration of the commited fix in
pg_reorg.
From inspecting the call sites of utoa, it appears that some of them
(especially the recent cleanup patch which added the strdup there) wanted
to prevent overwriting a local variable by repeated call (to utoa) using
the same variable as argument. This commit instead makes such call sites
strdup the variable itself before passing it to utoa. That seems cleaner
considering that it does not seem utoa's contract to do so (strdup its
parameter that is).
If there are two concurrent pg_repack commands are run on the same
table, the one starting later fails with error message:
Another pg_repack command may be running on the table. Please try again.
The document says this is shown as ERROR, but actualy is WARNING.
This patch includes one global counter (temp_obj_num) which counts number of temporary objects created by pg_repack. Correct order of deletion of temporary object as per count avoids unintentional error messages.
pgut version renamed to avoid confusion with the server version.
(I wonder why there is such a duplication of interfaces and
implementations there though...)
Previously, pg_repack shows "ERROR: ERROR: relation foo does not
exist" when specify non-existing table. Though the first ERROR
is from pg_repack and the second ERROR is from PostgreSQL server,
some users might think that pg_repack shows error level twice
wrongly.
