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
fromthere
That would allow OS upgrades not to impact running instances until they do ALTER EXTENSION UPDATE; and allowing
co-existenceof different versions of the same extension in different clusters of the same major version, and maybe
inseparate 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
preventingus 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
