Commit 5adff6ff0b 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.
The storage option such as AUTOVACUUM_VACUUM_SCALE_FACTOR can be
set to both heap table and TOAST table. But the storage parameter
for TOAST table had gone after repacked. This change create new
function get_storage_param which returns all storage paramters
including for TOAST table and OID setting.
Issue #10.
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.
