We currently check and throw an error if the version loaded in the
client is different from the installed extension version, however
there is no way to recover from this state in a backend. (There is
no way to load the new version as we cannot unload the old and no
commands can be effectively run). Now, we instead throw a
FATAL error which will cause the client to reconnect so it can load
the proper extension version.
Replace hardcoded database name from regression tests with :TEST_DBNAME
Remove creation of database single_2 from test runner and add it to
bgw_launcher and loader test since no other tests used those
use SQL comments in test scripts
Previously, the GUC to let the versioned-extension know that
the loader was present was incorrectly reset during DISCARD ALL.
This caused newly minted parallel workers to throw an error
about the extension not being preloaded since it did not
know that a loader was, in fact, preloaded. This PR
fixes this issue by changing the GUC to a rendezvous variable.
It also disables the loader in parallel workers since the loading
should have been handled in the parallel leader and the worker
start-up logic.
Issuing "CREATE EXTENSION IF NOT EXISTS timescaledb;" generates
an error if the extension is already loaded. This change makes
this command work as expected, with a NOTICE.
Error messages related to CREATE EXTENSION have also been
updated to better adhere to the official PostgreSQL style
guide and also returns the same or similar error codes
and messages as regular PostgreSQL.
This PR adds the ability to have multiple different versions of the timescaledb
extension be used by different databases in the same PostgreSQL
instance (server).
This is accomplished by splitting this extension into two .so files.
1) timescaledb.so -- stuff under loader/. Really not a lot of code.
This code MUST be backwards compatible in the future.
2) timescaledb-version.so (most of our code). Need
not be backwards compatible.
Timescaledb.so becomes a small stub which is preloaded and whose main
reason for existing is to dynamically load the right
timescaledb-version.so when the time comes.
This change allows either of the above .so to be loaded in
shared_preload_libraries. But timescaledb.so allows for multiple
versions used on different databases in the same instance along
with smoother upgrades. Using timescaledb-version.so allows for
finer-grained control and lock-in and is appropriate in only a few
production environments.
This PR also adds version checking so that a clear failure message
will be displayed if the .so version does not match the SQL extension
version.
To support multi-version functionality we changed the way SQL update
scripts are generated. Previously, the system used a bunch of
intermediate upgrade scripts. So with 3 versions, you would have an
update script of 1--2, 2--3. But, this PR changes things so that we
produce direct "shortcut" update files: 1--3, 2--3.
This is done for 2 reasons:
1) Each of the update files should point to
$libdir/timescaledb-current_version. Since you cannot guarantee that
Previous .so for each intermediate version has been installed.
2) You don't want intermediate version updates installed without the
.so. For example, if you have versions 1,2,3
and you are installing version 3, you want the upgrade files 1--3,
2--3 but not 1--2 because if you have 1--2
then a user could do ALTER EXTENSION timescaledb UPDATE TO 2. But
the .so for version 2 may not be installed.
In order to test this functionality, we add a mock extension version .so
that we can test extension loading inside the regression framework.
