PG18 de retour, mises à jour nocturnes, tests de reprise et documentation

Image - Étape `base` commune : tous les paquets sont mis à niveau (PostgreSQL à la dernière mineure, pgvector, Debian). L'image de base de VectorChord restait figée à la version de sa publication. - En-têtes du serveur épinglés sur la version du serveur installé. PG18 avait été retiré parce que TimescaleDB, compilé avec des en-têtes 18.6, était chargé par un serveur 18.3 (`undefined symbol: palloc0_mul`). - Sonde de santé avec l'utilisateur et la base du conteneur : en `postgres`, elle écrivait une erreur FATAL au journal dès que POSTGRES_USER était défini. - Label `base.name` corrigé : il reprenait la version du paquet au lieu de la version majeure. CI - PG18 ajouté à la matrice. - Exécution nocturne : apt est interrogé dans l'image publiée ; elle n'est reconstruite et republiée que s'il lui reste des mises à jour, sinon elle est seulement testée. Lancement manuel possible. - `docker-build.yml` supprimé : l'ancien workflow à actions externes tournait encore à chaque push, en double de `docker.yml`. - `paths-ignore` : un push de documentation seule ne lance pas la CI. - Labels `version`, `url` et `fr.killinger.apt-refresh`. Tests - `tests.sh`, la même commande en local et en CI : utilisateur et base autres que `postgres`, version majeure du serveur, présence des cinq extensions, redémarrage, et reprise d'une base créée par l'image publiée. Documentation - README en vitrine, CLAUDE.md, docs/architecture.md, docs/exploitation/publication.md, six décisions, docs/a-faire.md.
2026-10-02 17:55:42 +02:00
1 parent 2a0f84e81a
commit 7de55c5655
@@ -0,0 +1,28 @@
+# À faire
+
+Ce fichier ne contient que l'ouvert. Un point terminé est supprimé.
+
+## Versions
+
+- **TimescaleDB 2.30.2 est disponible**, l'image épingle 2.28.3. Vérifié sur PostgreSQL 17 :
+  la 2.30.2 compile, passe les tests et reprend une base créée en 2.28.3 après
+  `ALTER EXTENSION timescaledb UPDATE`. Reste à le vérifier pour 15, 16 et 18, puis à suivre
+  la procédure de [exploitation/publication.md](exploitation/publication.md), base de Health
+  comprise.
+
+## CI
+
+- **Le cache de construction est borné à 8 Go, et les couches des quatre versions en pèsent
+  environ 7,3** (1,8 Go par version, dont 1,1 pour les outils de compilation), sur un cache
+  partagé avec les autres dépôts du runner. Une couche évincée est reconstruite au push
+  suivant. À mesurer sur Tower avant de relever la borne.
+- **Vérifier qu'un échec de l'exécution nocturne est notifié** par Gitea. Sinon, seuls la page
+  Actions et le badge du README le montrent.
+
+## Dépôt
+
+- **`init-timescale.sh` n'est copié dans aucune image.** À supprimer s'il ne sert plus.
+- **`build.sh` nomme l'image `timescaledb-vectorchord`**, un nom que rien d'autre n'utilise.
+- **`docker-entrypoint-wrapper.sh` refait `chown -R` sur tout le volume à chaque
+  démarrage.** Ne le faire que si le propriétaire n'est pas `postgres` éviterait le parcours
+  d'une grosse base.
@@ -0,0 +1,99 @@
+# Architecture
+
+```
+tensorchord/vchord-postgres:pgN-v1.1.1        PostgreSQL N, VectorChord, pgvector (Debian 12)
+        │
+        ▼
+     base ........ apt-get upgrade : PostgreSQL (mineure), pgvector, Debian
+        ├──▶ builder ... en-têtes du serveur + compilation de TimescaleDB
+        │                    │ bibliothèques et scripts SQL
+        ▼                    ▼
+     final ....... TimescaleDB copié, PostGIS (apt), scripts de démarrage
+        │
+        ▼
+gitea.killinger.fr/maxime.killinger/postgres-ts-vectors:pgN
+```
+
+Le même Dockerfile produit une image par version majeure de PostgreSQL, choisie par
+l'argument `PG_VERSION`. Les trois étapes s'enchaînent ainsi parce que le serveur et ses
+en-têtes doivent avoir la même version
+([0002](decisions/0002-paquets-a-jour-et-en-tetes-du-serveur.md)).
+
+## Fichiers
+
+| Fichier | Rôle |
+|---|---|
+| `Dockerfile` | Construction de l'image, en trois étapes |
+| `init-extensions.sh` | Création des extensions à l'initialisation de la base |
+| `docker-entrypoint-wrapper.sh` | Point d'entrée : droits du volume, puis point d'entrée de l'image `postgres` |
+| `tests.sh` | Tests de l'image, en local et en CI |
+| `tests/test-*.sql` | Contrôles joués sur une base neuve, un fichier par extension ou combinaison |
+| `tests/reprise-*.sql` | Données créées par l'image précédente, puis relues par la nouvelle |
+| `build.sh` | Construction locale d'une version |
+| `.gitea/workflows/docker.yml` | CI : construction, tests, publication, mises à jour nocturnes |
+
+## D'où vient chaque composant
+
+| Composant | Source | Version |
+|---|---|---|
+| PostgreSQL | image de base, puis `apt-get upgrade` (dépôt PGDG) | dernière mineure de la majeure |
+| VectorChord | image de base | `VCHORD_VERSION` du Dockerfile |
+| pgvector | image de base, puis `apt-get upgrade` (dépôt PGDG) | dernière disponible |
+| TimescaleDB | compilé depuis l'étiquette Git de la version | `TIMESCALEDB_VERSION` du Dockerfile |
+| PostGIS | paquet `postgresql-N-postgis-3` (dépôt PGDG) | dernière disponible |
+
+Pourquoi cet assemblage :
+[0001](decisions/0001-image-vectorchord-et-timescaledb-compile.md). Pourquoi deux versions
+sont épinglées et pas les autres :
+[0003](decisions/0003-versions-de-timescaledb-et-vectorchord-epinglees.md).
+
+## Étapes de construction
+
+- **`base`** part de l'image de VectorChord et met tous ses paquets à niveau. L'argument
+  `APT_REFRESH` ne sert qu'à invalider le cache de cette couche : sa valeur est affichée,
+  rien d'autre ne la lit.
+- **`builder`** part de `base`, installe les outils de compilation et les en-têtes du
+  serveur dans la version exacte du serveur installé, puis compile TimescaleDB et l'installe
+  dans `/tmp/timescaledb`.
+- **`final`** part de `base`, reçoit de `builder` les bibliothèques (`/usr/lib/postgresql/`)
+  et les scripts SQL (`/usr/share/postgresql/`) de TimescaleDB, installe PostGIS, copie les
+  deux scripts de démarrage et déclare la sonde de santé. Aucun outil de compilation n'y
+  entre.
+
+Labels de l'image : titre, description, source, auteur, licence et image de base sont dans
+le Dockerfile ; révision, version, date et clé `fr.killinger.apt-refresh` sont posés par la
+CI ([exploitation/publication.md](exploitation/publication.md)).
+
+## Démarrage du conteneur
+
+1. `docker-entrypoint-wrapper.sh` démarre en root, crée `/var/lib/postgresql` s'il manque,
+   en donne la propriété à `postgres` et le ferme aux autres utilisateurs. Un volume monté
+   arrive en effet avec les droits de son hôte.
+2. Il passe la main à `docker-entrypoint.sh`, le point d'entrée de l'image officielle
+   `postgres`, qui prend l'identité `postgres`.
+3. Sur un volume vide, ce point d'entrée initialise la base, démarre un serveur temporaire
+   et exécute `init-extensions.sh`, qui crée `timescaledb`, `vector`, `vchord`, `postgis` et
+   `postgis_topology` dans la base `POSTGRES_DB`. Sur un volume déjà initialisé, rien de
+   cela n'a lieu.
+4. Le serveur définitif démarre avec la commande de l'image :
+   `postgres -c shared_preload_libraries=timescaledb,vchord`. Les deux bibliothèques doivent
+   être préchargées pour que leurs extensions fonctionnent.
+
+La sonde de santé interroge `pg_isready` toutes les 30 secondes, avec l'utilisateur et la
+base du conteneur.
+
+## Données
+
+| Étiquette | Volume déclaré par l'image | Répertoire des données (`PGDATA`) |
+|---|---|---|
+| `pg15`, `pg16`, `pg17`, `latest` | `/var/lib/postgresql/data` | `/var/lib/postgresql/data` |
+| `pg18` | `/var/lib/postgresql` | `/var/lib/postgresql/18/docker` |
+
+Ces emplacements sont ceux de l'image officielle `postgres`, que l'image de base reprend.
+À partir de PostgreSQL 18, le répertoire porte le numéro de la version majeure, pour que
+deux versions cohabitent dans le même volume pendant un `pg_upgrade`. Une image `pg18` qui
+trouve un volume monté sur `/var/lib/postgresql/data` refuse de démarrer.
+
+Passer d'une version majeure à la suivante n'est pas un changement d'étiquette : les données
+d'une version ne sont pas lisibles par une autre sans `pg_upgrade` ou sauvegarde et
+restauration ([0006](decisions/0006-latest-reste-sur-postgresql-17.md)).
@@ -0,0 +1,32 @@
+# 0001 — Image de VectorChord en base, TimescaleDB compilé, PostGIS par apt
+
+## Contexte
+
+L'image doit réunir PostgreSQL, TimescaleDB, VectorChord, pgvector et PostGIS, pour plusieurs
+versions majeures de PostgreSQL. TensorChord publie `tensorchord/vchord-postgres`, qui
+contient déjà PostgreSQL, VectorChord et pgvector, construite sur l'image officielle
+`postgres` (Debian 12, dépôt de paquets PGDG).
+
+## Décision
+
+- L'image part de `tensorchord/vchord-postgres:pgN-vX.Y.Z`.
+- TimescaleDB est compilé depuis l'étiquette Git de sa version, dans une étape séparée. Seuls
+  ses bibliothèques et ses scripts SQL passent dans l'image finale.
+- PostGIS est installé par le paquet `postgresql-N-postgis-3` du dépôt PGDG.
+- Les extensions sont créées à l'initialisation de la base par un script de
+  `/docker-entrypoint-initdb.d/`, et la commande de l'image précharge `timescaledb` et
+  `vchord`.
+
+## Conséquences
+
+- Le même Dockerfile sert toutes les versions de PostgreSQL pour lesquelles TensorChord
+  publie une image.
+- Une construction sans cache compile TimescaleDB, ce qui prend plusieurs minutes par
+  version.
+- Les outils de compilation ne sont pas dans l'image publiée.
+- Variables d'environnement, point d'entrée et emplacement des données sont ceux de l'image
+  officielle `postgres`.
+
+## Attestée par
+
+`Dockerfile` ; `init-extensions.sh` ; `tests/test-*.sql`.
@@ -0,0 +1,38 @@
+# 0002 — Paquets mis à niveau à la construction, en-têtes épinglés sur le serveur
+
+## Contexte
+
+L'image de base n'est republiée qu'à chaque version de VectorChord. Entre deux, son
+PostgreSQL prend du retard sur les versions mineures et les correctifs de sécurité : une
+image de base contenait PostgreSQL 18.3 quand le dépôt PGDG en était à 18.6, avec une
+trentaine d'autres paquets en retard.
+
+La compilation de TimescaleDB installe les en-têtes du serveur par apt, donc dans la
+dernière version. Compilé avec des en-têtes 18.6 puis chargé par un serveur 18.3,
+TimescaleDB échouait à la création de l'extension (`undefined symbol: palloc0_mul`), sans
+erreur à la compilation. PostgreSQL 18 avait été retiré de la CI pour cette raison.
+
+## Décision
+
+- Une étape `base`, commune à la compilation et à l'image finale, met tous les paquets à
+  niveau (`apt-get upgrade --with-new-pkgs`). Le serveur publié est donc à la dernière
+  version mineure.
+- L'étape de compilation installe les en-têtes dans la version exacte du serveur installé,
+  lue par `dpkg-query`, et non dans la dernière disponible.
+- La couche de mise à niveau porte une clé de cache, l'argument `APT_REFRESH`.
+
+## Conséquences
+
+- PostgreSQL 18 est de nouveau construit et publié.
+- Serveur et en-têtes ne peuvent plus diverger : si la version voulue des en-têtes n'est
+  plus dans le dépôt, la construction échoue au lieu de produire une image qui ne charge
+  pas TimescaleDB.
+- La variable d'environnement `PG_VERSION` héritée de l'image de base n'est plus la version
+  du serveur.
+- Sans changement de `APT_REFRESH`, le cache garde la mise à niveau telle qu'elle a été
+  faite : c'est la CI qui décide quand la rejouer
+  ([0005](0005-mises-a-jour-nocturnes-pilotees-par-apt.md)).
+
+## Attestée par
+
+`Dockerfile` (étapes `base` et `builder`) ; commit `dcf4169`, qui avait retiré PostgreSQL 18.
@@ -0,0 +1,32 @@
+# 0003 — Versions de TimescaleDB et de VectorChord épinglées
+
+## Contexte
+
+TimescaleDB nomme sa bibliothèque d'après sa version (`timescaledb-2.28.3.so`), et une base
+retient la version de l'extension qu'elle a installée. L'image ne contient que la
+bibliothèque de la version compilée. Démarrée sur une base créée avec une autre version,
+elle refuse toute requête (`could not access file "$libdir/timescaledb-2.28.3"`) jusqu'à
+l'exécution de `ALTER EXTENSION timescaledb UPDATE`. Le serveur, lui, démarre et répond à
+`pg_isready`.
+
+Les versions mineures de PostgreSQL, pgvector et PostGIS n'ont pas cet effet : une base
+existante redémarre sur la nouvelle image sans intervention.
+
+## Décision
+
+- `TIMESCALEDB_VERSION` et `VCHORD_VERSION` sont écrits dans le Dockerfile. La CI ne les fait
+  jamais avancer d'elle-même.
+- Les changer est un commit, précédé du test de reprise et d'un avertissement aux
+  exploitants ([exploitation/publication.md](../exploitation/publication.md)).
+- Tout le reste suit apt ([0002](0002-paquets-a-jour-et-en-tetes-du-serveur.md)).
+
+## Conséquences
+
+- Aucune republication automatique ne peut rendre une base inutilisable.
+- TimescaleDB et VectorChord prennent du retard tant que personne ne change leur version.
+- Le test de reprise de `tests.sh` commence par mettre les extensions à niveau : il vérifie
+  que la procédure fonctionne, pas que la base repart sans elle.
+
+## Attestée par
+
+`Dockerfile` ; `tests/reprise-2-controle.sql`.
@@ -0,0 +1,36 @@
+# 0004 — CI sans action externe, cache du démon, une construction par version
+
+## Contexte
+
+La CI téléchargeait depuis GitHub, à chaque job, quatre actions (`checkout`,
+`setup-buildx`, `login`, `build-push`), une vingtaine de secondes chacune, pour des
+opérations que l'image du runner sait faire avec `git` et `docker`. `setup-buildx` créait un
+constructeur neuf, sans cache : TimescaleDB était recompilé à chaque job, 7 à 9 minutes par
+version. L'image était construite jusqu'à trois fois : pour les tests, pour la publication,
+puis pour `latest`. Tout push relançait la CI, même quand il ne touchait que la documentation.
+
+## Décision
+
+- Récupération du seul commit concerné par `git fetch --depth 1`, connexion au registre par
+  `docker login`, construction par `docker build --pull` avec le démon Docker du runner,
+  dont le cache persiste d'un job à l'autre.
+- Une seule construction par version : l'image testée est celle qui est poussée, et `latest`
+  est une seconde étiquette de la même image.
+- Les tests sont une commande du dépôt, `tests.sh`, la même en local.
+- `paths-ignore` sur `**.md` et `docs/**` : un push de documentation seule ne lance pas la CI.
+- Cache de construction borné à 8 Go, images sans étiquette supprimées en fin de job.
+
+## Conséquences
+
+- La CI ne dépend plus de la disponibilité de GitHub pour ses actions. Elle en dépend encore
+  pour le code source de TimescaleDB, quand il faut le recompiler.
+- La compilation n'est rejouée que si l'image de base, les paquets ou la version de
+  TimescaleDB changent.
+- Le runner doit donner accès à un démon Docker, ce qui est le cas du runner commun aux
+  dépôts de Health et aux sites.
+- Le cache est partagé avec les autres dépôts du runner, chacun le bornant à 8 Go.
+
+## Attestée par
+
+`.gitea/workflows/docker.yml` ; commit `2a0f84e` ; la même décision dans nk-environnement
+(`0011-ci-sans-action-externe.md`) et dans les dépôts de Health.
@@ -0,0 +1,42 @@
+# 0005 — Mises à jour nocturnes, déclenchées par ce qu'apt propose
+
+Complète [0002](0002-paquets-a-jour-et-en-tetes-du-serveur.md) et
+[0004](0004-ci-sans-action-externe.md).
+
+## Contexte
+
+Les images ne changeaient qu'à un push. Entre deux, elles ne recevaient ni version mineure de
+PostgreSQL ni correctif de sécurité. Le cache persistant du runner aggrave le problème : une
+couche `apt-get upgrade` déjà construite n'est jamais rejouée. Reconstruire sans cache chaque
+nuit recompilerait TimescaleDB quatre fois et republierait quatre images identiques aux
+précédentes.
+
+## Décision
+
+- La CI tourne chaque nuit. Pour chaque version, elle tire l'image publiée et y simule
+  `apt-get upgrade --with-new-pkgs`.
+- S'il reste des paquets à mettre à niveau, ou si l'image n'existe pas, elle construit avec
+  une nouvelle clé `APT_REFRESH`, teste et publie.
+- Sinon elle ne construit ni ne publie : elle joue les tests sur l'image publiée.
+- La clé d'une image est gardée dans son label `fr.killinger.apt-refresh`. Un push la
+  reprend quand l'image publiée est à jour, pour que le cache serve.
+- Les versions de TimescaleDB et de VectorChord ne sont pas concernées
+  ([0003](0003-versions-de-timescaledb-et-vectorchord-epinglees.md)).
+
+## Conséquences
+
+- Une version mineure de PostgreSQL ou un correctif Debian est publié la nuit qui suit son
+  arrivée dans apt, sans intervention.
+- Une nuit sans mise à jour coûte une simulation apt et les tests, par version.
+- L'état de référence est l'image publiée, pas le cache du runner : un cache perdu ne
+  provoque ni reconstruction ni publication inutiles.
+- Tant qu'une reconstruction échoue aux tests, rien n'est publié et elle est retentée la nuit
+  suivante.
+- La simulation et la construction utilisent la même commande apt : après une publication,
+  l'image n'a plus rien en attente et la nuit suivante ne reconstruit pas.
+- Une republication de l'image de base sous la même étiquette n'est reprise qu'à la
+  prochaine reconstruction, par `--pull`.
+
+## Attestée par
+
+`.gitea/workflows/docker.yml` (étape « Check for updates ») ; `Dockerfile` (`APT_REFRESH`).
@@ -0,0 +1,26 @@
+# 0006 — `latest` reste sur PostgreSQL 17
+
+## Contexte
+
+L'image est publiée pour PostgreSQL 15 à 18. `latest` désigne PostgreSQL 17, et la base de
+Health l'utilise, avec un volume monté sur `/var/lib/postgresql/data`. Les données d'une
+version majeure ne sont pas lisibles par la suivante, et l'image `pg18` attend son volume sur
+`/var/lib/postgresql`.
+
+## Décision
+
+- `latest` reste une seconde étiquette de `pg17`. L'arrivée de `pg18` ne la déplace pas.
+- Un nouveau projet choisit une étiquette `pgN` explicite.
+
+## Conséquences
+
+- Aucun exploitant ne change de version majeure en tirant `latest`.
+- `latest` ne désigne pas la version la plus récente de PostgreSQL.
+- Déplacer `latest` demandera une nouvelle décision, après migration des bases qui
+  l'utilisent (`pg_upgrade`, ou sauvegarde et restauration) et changement de leur point de
+  montage.
+
+## Attestée par
+
+`.gitea/workflows/docker.yml` (étape « Tag latest ») ; `docker-compose.yml` de
+health-workspace.
@@ -0,0 +1,110 @@
+# Publication et mises à jour
+
+Les images sont construites, testées et publiées par la CI (`.gitea/workflows/docker.yml`),
+jamais à la main. Un push sur `main` **est une publication** : il remplace les quatre images,
+dont `latest`. Personne ne pousse sans demande explicite de l'utilisateur.
+
+## Déclencheurs
+
+| Déclencheur | Effet |
+|---|---|
+| Push sur `main` | Construction, tests et publication des quatre versions. Sans effet si tous les fichiers modifiés sont des `.md` ou sous `docs/` |
+| Chaque nuit, 3 h 30 UTC | Tests des images publiées ; reconstruction et publication de celles qui ont des mises à jour |
+| Lancement manuel (`workflow_dispatch`) | Comme un push |
+
+## Chaîne de publication
+
+Un job par version de PostgreSQL (15, 16, 17, 18), sans action externe
+([0004](../decisions/0004-ci-sans-action-externe.md)) :
+
+1. Récupération du seul commit concerné et connexion au registre.
+2. **Recherche des mises à jour.** L'image publiée est tirée, et apt y simule une mise à
+   niveau. S'il reste des paquets à mettre à niveau, ou si l'image n'a jamais été publiée,
+   une nouvelle clé `APT_REFRESH` est tirée de l'heure. Sinon la clé de l'image publiée,
+   lue dans son label `fr.killinger.apt-refresh`, est reprise
+   ([0005](../decisions/0005-mises-a-jour-nocturnes-pilotees-par-apt.md)).
+3. **Construction** avec `docker build --pull`, par le démon Docker du runner. Avec une clé
+   reprise, tout sort du cache. Avec une clé nouvelle, les paquets sont mis à niveau et
+   TimescaleDB est recompilé. La nuit, cette étape est sautée quand l'image est à jour.
+4. **Tests** par `tests.sh`, avec l'image publiée comme image précédente : la nouvelle image
+   doit reprendre une base créée par celle qu'elle remplace. La nuit, sans reconstruction,
+   c'est l'image publiée elle-même qui est testée.
+5. **Publication** de `pgN`, seulement si les tests passent, puis de `latest` pour
+   PostgreSQL 17 ([0006](../decisions/0006-latest-reste-sur-postgresql-17.md)).
+6. Nettoyage : cache de construction borné à 8 Go, images sans étiquette supprimées.
+
+La CI ne déclenche aucun déploiement. Un conteneur passe à la nouvelle image quand son
+exploitant la tire et le recrée.
+
+| Secret du dépôt | Usage |
+|---|---|
+| `secrets.DOCKER_TOKEN` | Connexion au registre Gitea (compte `maxime.killinger`) |
+
+## Ce qui se met à jour seul, et ce qui ne le fait pas
+
+| Composant | Mise à jour |
+|---|---|
+| PostgreSQL (version mineure), pgvector, PostGIS, paquets Debian | Automatique, la nuit qui suit leur arrivée dans apt |
+| TimescaleDB, VectorChord | À la main, dans le Dockerfile ([0003](../decisions/0003-versions-de-timescaledb-et-vectorchord-epinglees.md)) |
+| Nouvelle version majeure de PostgreSQL | À la main, dans la matrice de la CI |
+
+Une mise à jour automatique ne demande rien à l'exploitant d'une base : le conteneur recréé
+repart sur ses données. Les extensions installées gardent la version de leurs objets SQL
+tant qu'on ne les met pas à niveau, ce qui reste facultatif pour pgvector et PostGIS :
+
+```sql
+ALTER EXTENSION vector UPDATE;
+SELECT postgis_extensions_upgrade();
+```
+
+## Changer la version de TimescaleDB
+
+1. Construire et tester en local contre l'image publiée, pour chaque version de PostgreSQL :
+   ```bash
+   docker build --build-arg PG_VERSION=17 --build-arg TIMESCALEDB_VERSION=2.30.2 -t postgres-ts-vectors:essai .
+   docker pull gitea.killinger.fr/maxime.killinger/postgres-ts-vectors:pg17
+   ./tests.sh postgres-ts-vectors:essai gitea.killinger.fr/maxime.killinger/postgres-ts-vectors:pg17
+   ```
+   Une version de TimescaleDB qui abandonne une version de PostgreSQL échoue à la
+   compilation : cette version de PostgreSQL sort alors de la matrice, ou garde l'ancienne
+   version de TimescaleDB.
+2. Changer `TIMESCALEDB_VERSION` dans le `Dockerfile`, le tableau et le badge du `README.md`.
+3. Prévenir les exploitants **avant** de pousser. Dès qu'un conteneur est recréé sur la
+   nouvelle image, sa base refuse toute requête jusqu'à l'exécution de :
+   ```bash
+   docker exec -it <conteneur> psql -X -U <utilisateur> -d <base> -c 'ALTER EXTENSION timescaledb UPDATE'
+   ```
+   La commande est à passer dans chaque base qui a l'extension. `-X` et une session neuve
+   sont nécessaires : l'instruction doit être la première de la session.
+
+## Changer la version de VectorChord
+
+Elle fait partie de l'étiquette de l'image de base. Vérifier que TensorChord publie
+`tensorchord/vchord-postgres:pgN-vX.Y.Z` pour les quatre versions de PostgreSQL, changer
+`VCHORD_VERSION` dans le `Dockerfile`, le tableau et le badge du `README.md`, puis tester
+comme pour TimescaleDB. Côté base : `ALTER EXTENSION vchord UPDATE`.
+
+## Vérifier une image publiée
+
+```bash
+IMAGE=gitea.killinger.fr/maxime.killinger/postgres-ts-vectors:pg17
+docker pull "$IMAGE"
+
+# Commit, date de construction, clé de mise à jour, image de base
+docker image inspect "$IMAGE" -f '{{json .Config.Labels}}'
+
+# Version du serveur et des paquets d'extensions
+docker run --rm --entrypoint sh "$IMAGE" -c \
+  'postgres --version; dpkg-query -W -f "\${Package} \${Version}\n" "postgresql-$PG_MAJOR-*" | grep " ."'
+
+# La suite de tests, sur l'image publiée
+./tests.sh "$IMAGE"
+```
+
+| Label | Contenu |
+|---|---|
+| `org.opencontainers.image.revision` | Commit du dépôt qui a construit l'image |
+| `org.opencontainers.image.created` | Date de construction |
+| `org.opencontainers.image.version` | Étiquette `pgN` |
+| `org.opencontainers.image.base.name` | Image de VectorChord dont elle part |
+| `fr.killinger.apt-refresh` | Clé de la dernière mise à niveau des paquets, à l'heure UTC |