fix: PostgreSQL krijgt dezelfde probes als MariaDB

changelog.d/0032-postgres-probes.md

@@ -0,0 +1,26 @@
+### Gewijzigd — 2026-08-05 (PostgreSQL krijgt dezelfde probes als MariaDB)
+
+`values/db/postgres.yaml` had geen `startupProbe`. Het opstartbudget was daarmee wat
+liveness toestond: `initialDelaySeconds: 30` + 6×10s = **90 seconden**. Krapper dan
+MariaDB had, en dat budget van 150s bleek op 2026-08-04 al te kort — twee
+MariaDB-tenants kwamen in een oneindige CrashLoopBackOff omdat de kubelet de
+container afschoot voordat de start klaar was.
+
+PostgreSQL doet bij een onreine stop WAL-recovery voordat hij connecties opent. Hoe
+groter de database, hoe reëler dat dit over 90 seconden gaat. Wordt hij daar middenin
+afgeschoten, dan begint recovery elke ronde opnieuw en komt hij nooit klaar. Data
+raakt niet corrupt — PostgreSQL is crash-safe — maar de tenant blijft down, en dat
+ziet er van buiten precies zo uit als de storing van gisteren.
+
+Nu 30s + 60×10s = 10 minuten, gelijk aan MariaDB en aan de platform-standaard voor de
+Nextcloud-container. Liveness op `initialDelaySeconds: 30`, dus strakker dan het
+chart-budget van 90s: een dode database wordt sneller opgemerkt, niet langzamer.
+
+Geverifieerd met `helm template` per profiel: postgres en mariadb geven beide
+`startup=630s liveness=30s`, en `external` levert terecht geen database.
+
+Dit is bewust pas nu gedaan. Het raakt 48 accept- en 26 productie-tenants, en op
+2026-08-05 bleek de canary-poort niets te keuren (probe groen 31s na de merge terwijl
+Argo's reconcile 180s is). Die poort is eerst gerepareerd — timing, een streak, en
+aankomst-verificatie via `/status.php` — zodat deze wijziging de eerste is die er
+langs komt met een canary die de wijziging daadwerkelijk had.

docs/HAVEN-COMPLIANCE.md

@@ -64,20 +64,23 @@ Het opstartbudget is dan wat liveness toestaat, en dat is kort: MariaDB kreeg
 `initialDelaySeconds: 120` + 3×10s ≈ 150s, PostgreSQL `initialDelaySeconds: 30`
 + 6×10s = 90s (gemeten via `helm template` op chart 8.9.0). Daarna schiet de
 kubelet de container af; bij een trage of hangende start levert dat een
-CrashLoopBackOff op in plaats van één zichtbare fout. Voor MariaDB is dat
-expliciet rechtgezet:
+CrashLoopBackOff op in plaats van één zichtbare fout. Voor **beide** in-cluster
+engines is dat expliciet rechtgezet:
 
 ```yaml
-# values/db/mariadb.yaml
+# values/db/mariadb.yaml én values/db/postgres.yaml
 primary.startupProbe: { enabled: true, initialDelaySeconds: 30, periodSeconds: 10, failureThreshold: 60 }
 primary.livenessProbe: { enabled: true, initialDelaySeconds: 30, periodSeconds: 10, failureThreshold: 3 }
 ```
 
-**Openstaand:** `values/db/postgres.yaml` heeft deze correctie nog niet en draait
-dus op die 90 seconden. PostgreSQL doet bij een onreine stop ook WAL-recovery,
-dus hetzelfde risico geldt daar — met een krapper budget dan MariaDB had. Dit is
-bewust buiten deze wijziging gehouden omdat het 55 van de 77 tenants raakt en een
-eigen sync-window verdient. Zie CHANGELOG 2026-08-05.
+Gemeten met `helm template` per profiel: beide geven een opstartbudget van 630s en
+liveness op 30s. Het `external`-profiel levert geen in-cluster database en heeft dus
+geen database-probes.
+
+PostgreSQL liep tot 2026-08-05 op 30s + 6×10s = 90 seconden, krapper dan MariaDB's
+150s. Bij een onreine stop doet PostgreSQL WAL-recovery voordat hij connecties
+opent; wordt hij daar middenin afgeschoten, dan begint recovery elke ronde opnieuw.
+Crash-safe, maar permanent down.
 
 ## 4. Resource governance
 

nextcloud-platform/values/db/postgres.yaml

@@ -26,6 +26,41 @@ postgresql:
       adminPasswordKey: postgres-password
       userPasswordKey: db-password
   primary:
+    # -------------------------------------------------------------------------
+    # Probes — zelfde reden als bij values/db/mariadb.yaml
+    # -------------------------------------------------------------------------
+    # Zonder startupProbe is het opstartbudget wat liveness toestaat, en dat was
+    # hier `initialDelaySeconds: 30` + 6×10s = 90 seconden. Krapper dan MariaDB had
+    # (150s), en dat budget bleek op 2026-08-04 al te kort: twee MariaDB-tenants
+    # kwamen in een oneindige CrashLoopBackOff omdat de kubelet de container
+    # afschoot voordat de start klaar was.
+    #
+    # PostgreSQL doet bij een onreine stop WAL-recovery voordat hij connecties
+    # opent. Hoe groter de database, hoe reëler dat dit over 90 seconden gaat; wordt
+    # hij daar middenin afgeschoten, dan begint recovery elke ronde opnieuw en komt
+    # hij nooit klaar. Data raakt niet corrupt — PostgreSQL is crash-safe — maar de
+    # tenant blijft down.
+    #
+    # Budget hieronder: 30s + (60 × 10s) = 10 minuten, gelijk aan MariaDB en aan de
+    # platform-standaard voor de Nextcloud-container.
+    startupProbe:
+      enabled: true
+      initialDelaySeconds: 30
+      periodSeconds: 10
+      timeoutSeconds: 5
+      failureThreshold: 60
+      successThreshold: 1
+
+    # Pas scherp zodra de startupProbe geslaagd is. Dat is strakker dan het
+    # chart-budget van 90s en merkt een dode database dus sneller op.
+    livenessProbe:
+      enabled: true
+      initialDelaySeconds: 30
+      periodSeconds: 10
+      timeoutSeconds: 5
+      failureThreshold: 3
+      successThreshold: 1
+
     initdb:
       scripts:
         01-enable-extensions.sql: |