What is the recommended way to install extensions that is not packaged in the Percona repo, like pg_cron, for use with the Percona PostgreSQL distribution?
We have been using the (Ubuntu DEB) packages from PGDG for it, but there are currently dependency conflicts (Percona’s packages indicates that the provide postgresql-15-jit-llvm=15 and the PGDG extensions (which are builds of the Debian sid packages) now have a conflict with postgresql-15-jit-llvm < 19) (This does not seem to actually break anything - the Percona packages possibly advertise the wrong JIT version and/or the PGDG ones unnecessarily have that conflict) (This is for postgresql 15 currently, but other versions has the same issue) (The Debian package explicitly define the LLVM version separately from the PostgreSQL version)
We currently have a relatively complex setup with repo pinning for some packages. (there was a dummy postgresql-jit-llvm package at a time to get the PGDG extension packages to install, the Percona ones started advertising that since then though)
Packages pinned to Percona repo to avoid issues with PGDG ones being installed:
postgresql-
postgresql-common
postgresql-client-common
(We are considering changing to the PGDG packages as primary, but need some more work to the automation to disable an initdb, which messes with Patroni’s setup) (And need to figure out how much things that might break on existing ones)
Do not install extensions you do not plan on actively be using. Because extensions can cause conflicts or add overhead. And thus, having (non used) extensions can impact negatively
I’m still mainly wondering what the recommended way to install extensions that Percona doesn’t package is for users of Percona’s distribution? (other repos (PGDG in my case) previously worked, but it is error prone)
The operator documents how to add extensions to the container, but I don’t see the equivalent for the PostgreSQL distribution documentation. (Installing from source would probably work, but I want to avoid compilers on the database servers)
As you already mentioned, PGDG may introduce conflicts so it’s not a fully compatible way of managing this. The possible solutions are to compile, or to find precompiled packages from other sources (like github releases). You can also create a new feature request so we can evaluate adding said extension to the distribution.
Regarding:
but I want to avoid compilers on the database servers
This makes sense. The solution is to use dedicated small servers for it (or even containers) that match OS, arch, package versions, etc., compile in them and then copy back the needed extension files (.so, .sql, etc). It requires some extra steps and planning, but it can definitely be done.
Thanks!
Including equivalents to the OS packages (including the extensions) would make life a bit easier, but that gets complicated by different OSes likely packaging different extensions.