On 22 Jul. 2017 04:19, "Mat Arye" <m...@timescaledb.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.
