Re: [HACKERS] Syncing sql extension versions with shared libraryversions
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] Syncing sql extension versions with shared libraryversions |
Дата | |
Msg-id | 92f8733a-ff31-b4e4-c591-811304150751@2ndQuadrant.com обсуждение исходный текст |
Ответ на | [HACKERS] Syncing sql extension versions with shared library versions (Mat Arye <mat@timescaledb.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Mat AryeДата:
Сообщение: [HACKERS] Syncing sql extension versions with shared library versions
Следующее
От: Tom LaneДата:
Сообщение: [HACKERS] Buildfarm failure and dubious coding in predicate.c