Re: [HACKERS] Syncing sql extension versions with shared library versions - Mailing list pgsql-hackers
| From | Craig Ringer |
|---|---|
| Subject | Re: [HACKERS] Syncing sql extension versions with shared library versions |
| Date | |
| Msg-id | CAMsr+YFfHsD6NkCTVOYoi8_fumhLh5ok7hdsV1n6Djcf9hHe7A@mail.gmail.com Whole thread Raw |
| In response to | [HACKERS] Syncing sql extension versions with shared library versions (Mat Arye <mat@timescaledb.com>) |
| List | pgsql-hackers |
(Re-added hackers to Cc as this doesn't seem private, just accidentally didn't reply-all?)
On 24 July 2017 at 23:50, Mat Arye <mat@timescaledb.com> wrote:
--
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.Yeah shared_preload_libraries is a special case I guess. Something like that could work with local_preload_libraries or session_preload_libraries right?
It could work, but since it doesn't offer a complete solution I don't think it's especially compelling.
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 faced 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.This is a good point. Thanks for bringing it to my attention. I guess if the CREATE FUNCTION call contained the name of the new .so then it would force a load, right? But that means you need to be safe with regard to having both .so file loaded at once (not sure that's possible). I think this is the biggest unknown in terms of whether a stub-loader /can/ work.
Unless both .so's have different filenames, you can't have both loaded in the same backend. Though if you unlink and replace the .so with the same file name while Pg is running, different backends could have different versions loaded.
If you do give them different names and they both get linked into one backend, whether it works will depend on details of linker options, etc. I wouldn't want to do it personally, at least not unless I prefixed all the .so's exported symbols. If you're not worried about being portable it's less of a concern.
Personally I just make sure to retain stub functions in the C extension for anything removed. It's trivial clutter, easily swept into a corner in a backward compat file.
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.Yeah that's very similar to what we do now. It doesn't work for multiple dbs having different extension versions, though (at least for us).
Makes sense. Not a case I have ever cared to support.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql-hackers by date: