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.
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...)
Prior to 506104686b these DELETEs had been done in large batches (of
DEFAULT_PEEK_COUNT size), but that naive method of choosing rows to
delete was unsafe. Here we continue to keep track of which rows must
be deleted as we process them.
Adds support for repacking only the tables in a specified schema. This
doesn't support --only-indexes mode, but that seems alright for now.
Fix merge conflicts, and make a few tweaks along the way:
* bump version to 1.3-dev0
* add Beena to list of maintainers
* documentation wordsmithing
* fix up the INFO message printed for each index in --index or
--only-indexes mode, so that it is only printed once per index, and
prints the name of the original index, not that of the transient
index_%u name.
It is not safe to assume that we can bulk-delete all entries from the
log table based on their "id" being less than the largest "id" we have
processed so far, as we may unintentionally delete some tuples from the
log which we haven't actually processed yet in the case of concurrent
transactions adding tuples into the log table.
* Make sure we don't crash if this function is fed a bogus OID
* rename idx1, idx2 variables for clarity
* tweak query against pg_class to specify reltype = 0
* CommandCounterIncrement() is probably unnecessary, removed
Per Issue #7 from armanddp, it seems the RHEL/CentOS packages
of Postgres are built against libpam, which shows up in
the LIBS reported by pg_config. We don't actually need to
link in libpam for pg_repack, so manually remove it from
our LIBS. This helps a little bit for building on
RHEL/CentOS, though the issue of libpgport.a missing
on that platform still looms.
The -E flag to specify extended regular expressions apparently is
not portable to all platforms, such as CentOS 4.5. Use an uglier
but hopefully more portable basic regular expression in Makefiles.
Makes injecting the target tablespace much easier and fixes interaction
between tablespace and WITH/WHERE clauses.
Added tests to check the correct indexes definition.
Not as available as I thought.
Can't use the 0 prefix to make the 3rd number optional as $(()) parses is as
octal, so only use the first 2 numbers.
Also fixed collate test: not available on PG 9.0.
In the previous commit skip_const was going ahead the space thus removing the
starting quote. Also fixed (and tested) trailing part after the tablespace
name, e.g. the WHERE clause.
Note: if original namespace is "foo bar", repack_indexdef gives a bad
result. This is weird as apparently skip_ident can deal with spaces in
a quoted identifier. Committing as I'm going home, will deal with that
later.
Bumped version number to enforce extension re-creation as the SQL has
been modified.
Current limitations:
- Check for namespace existence: on error temp objects are left around
- What happens to the indexes?
- Tests needed.
- Should the default be the GUC default_tablespace instead of pg_default?
This is actually an original pg_repack shortcoming, not a regression.
Having the SQL on a different numbering scheme is useful to provide an ungrade
path. But pg_repack has no need of such a path as it can be uninstalled with
no problem, so we are not going to provide update script. Hence it's much
easier to have a single version number for everything.
