pg_repack needs to take an exclusive lock at the end of the
reorganization. If the lock cannot be taken after duration
--wait-timeout option specified and this option is true,
pg_repack gives up to repack a target table instead of
cancelling conflicting backend. False by default.
During repacking table, if a transaction executes INSERT CONFLICT
ON UPDATE/DO NOTHING, because we define BEFORE trigger on target
table, the contents of operation log table becomes inconsistent
easliy. As a result, pg_reapck fails with a high probability.
To resolve this issue, this changes the trigger type from BEFORE
to AFTER. We define AFTER trigger that is the first of the AFTER
trigger to fire on the table.
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.
* More mentions of new --only-indexes feature
* Note we now support up to Postgres 9.3, and get rid of outdated list
of supported operating systems. (As far as we know, pg_repack should
build on any platforms supported by PostgreSQL itself, although no one
has tested the Windows build in a long time.)
* Remove most of the warnings about data corruption possible with concurrent
DDL: this should no longer be a concern now that we hold an ACCESS SHARE
lock during full-table repacks. Keep a short warning about old versions
being susceptible to this problem, just to make clear that it's fixed now
and as an enticement to upgrade.
* A few grammar, phrasing, and typo fixes
--no-order now is almost useless, but list it next to --order-by.
--jobs only specifies how to do something, not what to do. On the
same basis probably --no-analyze should be pushed further up.
Actually this leaves out the case of the SQL schema not consistent with the
library/binary installed, and this is a relatively likely case:
the user has run "make install" but the repack schema was already loaded
from an older version.
repack_all_database can return an error message: in case of any error different
from "missing schema" return the error and keep processing the other databases
instead of printing and stopping the program.
The output of the program is now something like:
$ pg_reorg --all
pg_reorg: reorg database "contrib_regression"
pg_reorg: reorg database "template1" ... skipped: pg_reorg is not installed in the database
