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.
...not the other way around. This allows DROP EXTENSION ... CASCADE to
remove temporary directories, simplifying the cleanup procedure after an
error, and getting rid of the schema on uninstall.
Provide only CREATE EXTENSION support on PG >= 9.1 and only the sql script on
PG < 9.1.
Also dropped the /echo cruft in the extension script: it is broken on pg 9.1
and 9.1.1, and because the script is not installed on versions that don't
support CREATE EXTENSION it is just not terribly useful.
pg_repack doesn't create any object to depend on, so it is always possible drop
it and install a new version instead of upgrading. Creating a robust upgrade
path from loose objects which can be of any version to a target version is
hopelessly brittle, so I'd suggest the user just to drop a previous pg_repack
version and install the new one.
