Hi,
This topic gets back at every release, more often now that we have
proper Extensions with ability to dump&restore. Lately the guys from
Open Shift project (a Red Hat team) have asked for a way to load DSO
module files from user-owned directory.
The way they make that safe is by using cgroups and SELinux, IIUC.
We can attack the problem in several ways:
- have an initdb switch to tweak the library path per cluster,
- have a superuser-only GUC to tweak the library path,
- consider on-disk extension as templates and move their module files
somewhere private in $PGDATA and load the code from there
That would allow OS upgrades not to impact running instances until
they do ALTER EXTENSION UPDATE; and allowing co-existence of
different versions of the same extension in different clusters of
the same major version, and maybe in separate databases of the same
cluster in some cases (depends on the extension's module specifics),
- do nothing even though the current solution is clearly broken, as in
not allowing to answer several user needs and preventing us to
implement full support (e.g. base backups, hot standby) for
extensions.
This proposal comes with no patch because I think we are able to
understand it without that, so that it would only be a waste of
everybody's time to attach code for a random solution on the list here
to that email. Or consider that the fourth point is currently the only
one addressed in this very proposal…
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
