* KILL_COMPETING_LOCKS was using pg_cancel_backend() instead of
pg_terminate_backend()
* create kill_ddl() function for canceling+terminating any pending
unsafe concurrent DDL, i.e. anyone hanging out waiting for
an ACCESS EXCLUSIVE lock on our table.
* create lock_access_share() function for reliably obtaining an
ACCESS SHARE lock on the target table, killing off any queued
ACCESS EXCLUSIVE lockers in the process via kill_ddl()
* Avoid deadlock possible before we run:
CREATE TABLE reorg.table_xxx AS SELECT ... FROM ONLY ...
by using lock_access_share()
* Fix a few calls in lock_exclusive() which were forgetting to
specify the passed-in connection.
These fixes are related to Issue #8. The main thing remaining AFAIK
is to review or fix some of the unlikely-error handling bits;
most of these should be marked with XXX now.
Fix table locking so that race conditions don't exist between lock
release in primary conn, and lock acquisition in conn2. Also, have
conn2 be in charge of performing the table swap step, to avoid a
similar race.
Part of work for Issue #8.
This is a first pass at Daniele's suggestion in Issue #8, although it is
definitely still buggy -- it is still possible for another transaction
to get in an AccessExclusive lock and perform DDL either before the
ACCESS SHARE lock is acquired or immediately after it is released.
Actually this leaves out the case of the SQL schema not consistent with the
library/binary installed, and this is a relatively likely case:
the user has run "make install" but the repack schema was already loaded
from an older version.
repack_all_database can return an error message: in case of any error different
from "missing schema" return the error and keep processing the other databases
instead of printing and stopping the program.
The output of the program is now something like:
$ pg_reorg --all
pg_reorg: reorg database "contrib_regression"
pg_reorg: reorg database "template1" ... skipped: pg_reorg is not installed in the database
Having the SQL on a different numbering scheme is useful to provide an ungrade
path. But pg_repack has no need of such a path as it can be uninstalled with
no problem, so we are not going to provide update script. Hence it's much
easier to have a single version number for everything.
...not the other way around. This allows DROP EXTENSION ... CASCADE to
remove temporary directories, simplifying the cleanup procedure after an
error, and getting rid of the schema on uninstall.
Provide only CREATE EXTENSION support on PG >= 9.1 and only the sql script on
PG < 9.1.
Also dropped the /echo cruft in the extension script: it is broken on pg 9.1
and 9.1.1, and because the script is not installed on versions that don't
support CREATE EXTENSION it is just not terribly useful.
pg_repack doesn't create any object to depend on, so it is always possible drop
it and install a new version instead of upgrading. Creating a robust upgrade
path from loose objects which can be of any version to a target version is
hopelessly brittle, so I'd suggest the user just to drop a previous pg_repack
version and install the new one.
The behaviour of the script is not really predictable if it is run on the
loose objects of pg_reorg >= 1.1.8. So let's be explicit about what version
we expect as starting point.
I've changed lib/Makefile to support CREATE EXTENSION.
In order to work with previeous PostgreSQL version (i.e. < 9.1),
this implementation installs both pg_reorg--1.0.sql and pg_reorg.sql.
This patch lacks regression testcases for CREATE EXTENSION, which I will commit soon.
