Re: Syncing sql extension versions with shared library versions

On 22 Jul. 2017 04:19, "Mat Arye" <mat(at)timescaledb(dot)com> wrote:

Hi All,

I am developing the TimescaleDB extension for postgres (
https://github.com/timescale/timescaledb) and have some questions about
versioning. First of all, I have to say that the versioning system on the
sql side is wonderful. It's really simple to write migrations etc.

However when thinking through the implications of having a database cluster
with databases having different extension versions installed, it was not
apparently clear to me how to synchronize the installed extension version
with a shared library version. For example, if I have timescaledb version
0.1.0 in one db and version 0.2.0 in another db, I'd like for
timescaledb-0.1.0.so and timescaledb-0.2.0.so to be used, respectively. (I
want to avoid having to keep backwards-compatibility for all functions in
future shared-libraries). In our case, this is further complicated by the
fact that we need to preload the shared library since we are accessing the
planner hooks etc. Below, I'll describe some solutions I have been thinking
about, but wanted to hear if anyone else on this list has already solved
this problem and has some insight. It is also quite possible I am missing
something.

Issue 1: Preloading the right shared library.
When preloading libraries (either via local_preload_libraries, or
session_preload_libraries, shared_preload_libraries), it would be nice to
preload the shared_library according to it's version. But, I looked through
the code and found no logic for adding version numbers to shared library
names.

You can't do that for shared_preload_libraries, because at
shared_preload_libraries time we don't have access to the DB and can't look
up the installed extension version(s). There might be different ones in
different DBs too.

Solution 1: Set session_preload_libraries on the database via ALTER
DATABASE SET. This can be done in the sql and the sql version-migration
scripts can change this value as you change extensions versions. I think
this would work, but it seems very hack-ish and less-than-ideal.

Won't work for some hooks, right?

I've faces this issue with pglogical and BDR. If the user tries to update
the extension before a new enough .so is loaded we ERROR due to failure to
load missing C functions.

If the .so is updated first the old extension function definitions can fail
at runtime if funcs are removed or change signature, but won't fail at
startup or load.

So we let the C extension detect when it's newer than the loaded SQL ext
during its startup and run an ALTER EXTENSION to update it.

We don't attempt to support downgrades.