An alternative way to fix#168 which is not as invasive as the changes
in #171.
This currently breaks the current behaviour of the program as the tables
specified on command line are not found.
Previously we exited from lock_exclusive() while opening the
transaction that started at beggning if --no-kill-backend option
is specified. This caused that DROP INDEX CONCURRENTLY fails
because it cannot be executed within a user transaction block.
Fixed issue #129.
Commit 5adff6ff0b88d6f162719eff7176069730537c2a separated the
data copy from creating table. This is a cause of bug that
pg_repack doesn't actually sort table during reorganization.
This commit fixes this issue by adding ORDER BY clause to Copy
SQL rather than CREATE TABLE SQL.
Reported by acmzero on issue #138.
There was a conservative wait[1] for all existing transaction to
finish before repacking a table. This may not be desired on a busy
database on which you have long running transaction, which may block
pg_repack to do the job. This option will display a warning message,
but continues the process in such cases.
[1] http://lists.pgfoundry.org/pipermail/reorg-general/2015-October/000318.html
__attribute__ macro is not defined in msvc and it is not essential to
the implementation. All it does is tell the compiler that this function
is similar to printf, and expects a printf-like format string
So for MSVC we define __attribute__ as a macro that do nothing
Previously, even if the table whose column storage type has been
changed the pg_repack did first copy the data to table without changing
column storage paramater. This cause of that the existing data is
pushed out to its toast table even if actual column storage type is
"main".
Issue #94.
Fix issue #24. The OP reported that the issue is solved by dropping this
assignment. The one in regress has been already dropped in the
refactoring to drop pre-9.1 support.
The current client checks for superuser before attempting to
execute pg_repack commands. In Amazon RDS, customers are given
access to a psuedo-superuser role called rds_superuser, but they
are not given access to superuser. However, rds_superusers will
otherwise have the ability to execute pg_repack commands in RDS.
This change introduces the --no-superuser-check option in the
client code so that users can disable the client-side superuser
checks.
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.
