Re: Syncing sql extension versions with shared library versions

On 07/21/2017 04:17 PM, Mat Arye 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 <http://timescaledb-0.1.0.so>
> and timescaledb-0.2.0.so <http://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.
> 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.
> Solution 2: Create some kind of stub shared-library that will, in
> turn, load another shared library of the correct version. This seems
> like the cleaner approach. Has anybody seen/implemented something like
> this already?
>
> Issue 2: module_pathname
> I believe that for user defined function the MODULE_PATHNAME
> substitution will not work since that setting is set once
> per-extension. Thus, for example, the migration scripts that include
> function definitions for older versions would use the latest .so file
> if MODULE_PATHNAME was used in the definition. This would be a problem
> if upgrading to an intermediate (not latest) version.
> Solution: MODULE_PATHNAME cannot be used, and we should build our own
> templating/makefile infrastructure to link files to the
> right-versioned shared library in the CREATE FUNCTION definition.
>
>

It would be nice if we could teach yhe load mechanism to expand a a
version escape in the MODULE_PATHNAME. e.g.

MODULE_PATHNAME = '$libdir/foo-$version'

cheers

andtrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services