maxime.killinger
7de55c5655
🚀 Docker Build and Push / build-and-push (15) (push) Successful in 5m29s
🚀 Docker Build and Push / build-and-push (16) (push) Successful in 6m10s
🚀 Docker Build and Push / build-and-push (17) (push) Successful in 5m20s
🚀 Docker Build and Push / build-and-push (18) (push) Successful in 5m21s
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.
33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# 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`.
|