The run part has different output across minor versions, the others not.
Dropped test files identification statement as now the variable part is
in small chunks.
Due to compatibility break by the recent PostgreSQL core code changes
we need to split expected files into each minor releases rather than
each major releases.
Now the mapping between PostgreSQL version and expected file is
complicated as follows.
* version 10
* >= 10.3 : repack_3.out, tablespace_2.out
* < 10.3 : repack_2.out, tablespace.out
* version 9.6
* >= 9.6.8 : repack_4.out, tablespace_2.out
* < 9.6.8 : repack.out, tablespace.out
* version 9.5
* >= 9.5.12 : repack_4.out, tablespace_2.out
* < 9.5.12 : repack.out, tablespace_1.out
* version 9.4
* >= 9.4.17 : repack_5.out, tablespace_2.out
* < 9.4.17 : repack_1.out, tablespace_1.out
* version 9.3
* >= 9.3.22 : repack_6.out, tablespace_3.out
* < 9.3.22 : repack_1.out, tablespace_1.out
* version 9.2 : repack_1.out, tablespace_1.out
* version 9.1 : repack_1.out, tablespace_1.out
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.
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.
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.
It was possible to specify both --schema and --table which probably
-should- be legal but would need some code to be rewritten. This patch
adds a check that both can't be specified and returns an error telling
the user to use schema.table notation instead. A regression test
checking this behaviour was added.
