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
Due to change at PostgreSQL 10.3, 9.6.8, 9.5.12, 9.4.17 and 9.3.22,
relation names passed by PostgreSQL function such as
pg_get_indexdef_string() are schema-qualified, which could be cause
of a parse error.
__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.
Because commit 23a27b039d94ba359286694831eafe03cd970eef has extended the
type of SPI_processed from uint32 to uint64, pg_repack emit warning when
compiling with PostgreSQL 9.6 or later. To fix that, we cast it to uint64
and change format identifier from %d to %lu.
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.
Concurrent activity on the target table can cause deadlocks when
repack_drop() is doing its job, ie, dropping the temporary objects
created. It is highly likely to occur when pg_repack is interrupted
midway through its processing.
By commit 7b1c2a0f2066672b24f6257ec9b8d78a1754f494 in PostgreSQL,
builtins.h is splitted to a new header file ruleutils.h.
The usage of pg_get_indexdef_string in lib/repack.c is affected.
Control symbol visibility for functions exported in the pg_repack
shared library, to avoid symbol conflicts with other libraries,
particularly those which may be loaded via shared_preload_libraries
and use conflicting function definitions of our common pgut code,
such as pg_statsinfo.
Verified this fix on my Debian x86_64 machine with PostgreSQL 9.4 and
pg_statsinfo 3.0.2. Would be nice to test this fix on a few other
platforms such as OS X, though I had some difficulty getting
pg_statsinfo to build on OS X. Hopefully closes Issue #43, thanks
to bwtakacy for the report and demonstration of the commited fix in
pg_reorg.
This patch includes one global counter (temp_obj_num) which counts number of temporary objects created by pg_repack. Correct order of deletion of temporary object as per count avoids unintentional error messages.
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.
