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.
"Waiting for %d transactions to finish. First PID: %s"
message. Display it on every loop through the SQL_XID_ALIVE check
(i.e. every second), instead of only when the number of transactions
we're waiting on changes -- previously, it was too easy for that
important message to get lost in other messages.
And don't display the message at all when running under pg_regress,
i.e. as part of `make installcheck`. We had been getting occasional
errors from pg_regress when autovacuum was running and that message
got logged.
These calls can require an access share lock on the table, which might
conflict with an existing or later acquires lock. So perform these calls
while we already have an exclusive lock on the table. This unfortuantely
means that we ave to remove the constness of the table parameter to
repack_one_table, as it is not modifying the table object to set up the
indexes.
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.
4-byte int accepted by the two-argument form of pg_try_advisory_lock()
we are using.
Fixes#30. Thanks to Mark Steben and Greg Sabino Mullane for the report
and diagnosis.
