Skip to content

Commit

Permalink
Some tweaks, thanks to feedback from @ahachete
Browse files Browse the repository at this point in the history
  • Loading branch information
theory committed Nov 14, 2024
1 parent 714a4e4 commit 2433edc
Showing 1 changed file with 23 additions and 21 deletions.
44 changes: 23 additions & 21 deletions content/post/postgres/rfc-extension-packaging-lookup.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ description: |
A proposal to modify the PostgreSQL core so that all files required for an
extension live in a directory named for the extension, along with a search
path to find extension directories.
tags: [Postgres, Extensions, RFC, Packaging, Kubernetes, Docker, Packaging, Postgres.app]
tags: [Postgres, Extensions, RFC, Packaging, Kubernetes, OCI, Packaging, Postgres.app]
type: post
draft: true
---
Expand Down Expand Up @@ -44,15 +44,16 @@ the patch will search in `/tmp/build/myext/opt/share`. This approach works for
the packaging use case, which explicitly uses full paths with a prefix, but
would be weird for other use cases.

### Docker Immutability
### OCI Immutability

Docker images are immutable. To install persistent extensions in a running
Docker container, one must create a persistent volume, map it to
`SHAREDIR/extensions`, and copy over all the core extensions (or muck with
[symlink magic]). Then do it again for shared object libraries (`PKGLIBDIR`),
and perhaps also for other `pg_config` directories, like `--bindir`. Once it's
all set up, one can install a new extension and its files will be distributed
to the relevant persistent volumes.
[OCI] (née Docker) images are immutable, while a container running an image
contains a writeable but non-persistent file system. To install persistent
extensions in a running container, one must create a persistent volume, map it
to `SHAREDIR/extensions`, and copy over all the extensions it needs (or muck
with [symlink magic]). Then do it again for shared object libraries
(`PKGLIBDIR`), and perhaps also for other `pg_config` directories, like
`--bindir`. Once it's all set up, one can install a new extension and its
files will be distributed to the relevant persistent volumes.

This pattern makes upgrades tricky, because the core extensions are mixed in
with third-party extensions. Worse, the number of directories that must be
Expand Down Expand Up @@ -228,10 +229,10 @@ This will allow PostgreSQL to find and load the extension during the tests.
The Postgres installation will not have been modified; only the
`extension_path` will have changed.

### Docker/Kubernetes
### OCI/Kubernetes

To allow extensions to be added to a Docker container and to persist beyond
its lifetime, one or more [volumes] could be used. A couple of options:
To allow extensions to be added to a OCI container and to persist beyond its
lifetime, one or more [volumes] could be used. A couple of options:

* Mount the `--extdir-site` and/or `--extdir-vendor` directories as
persistent volumes (or one volume and a subdirectory for each). Then any
Expand All @@ -240,11 +241,11 @@ its lifetime, one or more [volumes] could be used. A couple of options:
uses the same persistent volume(s), can access the same extensions.

* Create separate images for each extension, and then "install" them by
using the [Kubernetes image volume feature] to mount them as read-only
volumes in the appropriate subdirectory of `--extdir-site` or
`--extdir-vendor`. Thereafter, any new containers would simply have to
mount all the same extension image volumes persistently provide the same
extensions to all containers.
using the [Kubernetes image volume feature] (currently in alpha) to mount
them as read-only volumes in the appropriate subdirectory of
`--extdir-site` or `--extdir-vendor`. Thereafter, any new containers would
simply have to mount all the same extension image volumes persistently
provide the same extensions to all containers.

### Postgres.app

Expand Down Expand Up @@ -397,11 +398,11 @@ shared_preload_extensions = 'pg_partman'
```

To load a single shared module from an extension, give its name after the
extension name and a slash. This example will load only the `pg_partman_bgw`
shared module from the `pg_partman` extension:
extension name and two colons. This example will load only the
`pg_partman_bgw` shared module from the `pg_partman` extension:

```ini
shared_preload_extensions = 'pg_partman/pg_partman_bgw'
shared_preload_extensions = 'pg_partman::pg_partman_bgw'
```

This change requires a one-time change to existing preload configurations on
Expand Down Expand Up @@ -459,7 +460,7 @@ the `*_preload_libraries` GUCs along with it.
This RFC does not include or attempt to address the following issues:

* How to manage third-party shared libraries. Making system dependencies
consistent in a Docker/Kubernetes environment or for non-system binary
consistent in a OCI/Kubernetes environment or for non-system binary
packaging patterns presents its own challenges, though they're not
specific to PostgreSQL or the patterns described here. Research is ongoing
into potential solutions, and will be addressed elsewhere.
Expand All @@ -469,6 +470,7 @@ This RFC does not include or attempt to address the following issues:
[discussion]: https://postgr.es/m/[email protected]
[Christoph Berg]: https://www.df7cb.de
[destdir]: https://commitfest.postgresql.org/50/4913/
[OCI]: https://opencontainers.org "Open Container Initiative"
[symlink magic]: https://speakerdeck.com/ongres/postgres-extensions-in-kubernetes?slide=14
"Postgres Extensions in Kubernetes: StackGres"
[Kubernetes image volume feature]: https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/
Expand Down

0 comments on commit 2433edc

Please sign in to comment.