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.
problem: in case there are open transactions on other databases then the
one pg_repack is working on and pg_locks doesn't contain any
information about the affected database oid of the locked relation
(e.g. there is no locked relation, only an open transaction),
pg_repack will wait for that connection to release the lock
(even if the relation that gets reorganized is held in an
different database).
solution: join pg_database (via pg_stat_activity's datid) and check
if the connection (of the conflicted transaction) is established
on a different database than the relation treated by pg_repack
and skip them.
furthermore don't exclude transactions from other databases when
shared objects are locked.
* 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
Previously, any error creating the temp index was blamed on a previous
temporary index existing. However, other errors could occur, e.g. if
--tablespace=pg_global was specified. Perform an explicit check for
whether an existing index_xxxxx already exists first, so that we
can give that error message only in the appropriate case.
* Avoid using create_idx from a PGresult that's already been PQclear'ed
* Now that we're properly tracking which indexes have been repacked,
don't bother with IF EXISTS in DROP INDEX. Better to make any errors
here stand out.
* Fix error handling in repack_table_indexes() to keep track of which
indexes were actually rebuilt successfully by pg_repack, so that only
those indexes will be dropped. Previously, we would issue an error
message telling the user to use DROP INDEX but then just drop the
index anyway.
* DROP INDEX command needs to quote the schema name in case it is
not simple.
* missing CLEARPGRES() in repack_all_indexes()
Improve locking behavior in indexes-only mode so we only need one
ACCESS EXCLUSIVE lock per table instead of one per index. Support
multiple --index options. Fix for schema-name parsing.
Patch from Beena Emerson.
Switch to using the two-input form of pg_advisory_lock(), so as
to avoid impacting other applications which might happen to lock
just the OID of the table. The REPACK_LOCK_PREFIX_STR is a decimal
version of the first three bytes of
echo -n "pg_repack" | sha1sum
Since we are not starting a new transaction in conn2 during the
swap step, we need to make sure that if our LOCK query is canceled
due to statement_timeout that conn2's transaction is not left in
a useless error state. Use SAVEPOINT and ROLLBACK TO SAVEPOINT to
avoid this problem.
--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.
Note: if original namespace is "foo bar", repack_indexdef gives a bad
result. This is weird as apparently skip_ident can deal with spaces in
a quoted identifier. Committing as I'm going home, will deal with that
later.
Bumped version number to enforce extension re-creation as the SQL has
been modified.
Current limitations:
- Check for namespace existence: on error temp objects are left around
- What happens to the indexes?
- Tests needed.
- Should the default be the GUC default_tablespace instead of pg_default?
This is actually an original pg_repack shortcoming, not a regression.
This simplifies some of the error handling blocks, as now
we can unconditionally use this macro without worrying about multiple
PQclear() calls causing a double-free().
Per discussion with Daniele.
