Context
The postgres service healthcheck in docker-compose.yml (pg_isready -U gittensory, interval: 10s, retries: 5) has no start_period, and neither does pgbouncer's. Every other service with a genuine cold-start delay in the same file was given an explicit start_period in the prior hardening pass (qdrant, ollama, browserless, rees, reporting-exporter, tempo, and the core gittensory app itself, whose comment explicitly says its 60s start_period "tolerates the Postgres cold start"). Postgres — the one service furthest upstream in that dependency chain — was skipped.
Docker's healthcheck state machine counts every failed probe toward retries from the very first check unless start_period is set. On a pgvector/pgvector:pg16 image doing a genuinely cold initdb (creating the pgvector extension, first-boot WAL setup) under real-world conditions (slow disk, low-memory VPS, first pull), 5 consecutive failures at a 10s cadence (~50s) is plausible. Once Docker marks postgres unhealthy, docker compose up fails the gittensory/pgbouncer/postgres-exporter depends_on: condition: service_healthy gates outright, rather than tolerating a slow-but-successful cold start.
Requirements
- Add an explicit
start_period (e.g. 20-30s, matching the pattern used for qdrant/ollama/rees) to the postgres healthcheck.
- Add the same to
pgbouncer's healthcheck, which also lacks one and depends transitively on Postgres being genuinely ready.
Acceptance criteria
- A cold
docker compose up on a slow/first-pull host tolerates a realistic Postgres initdb duration without failing dependent services' startup gates.
Parent: #1667
Context
The
postgresservice healthcheck indocker-compose.yml(pg_isready -U gittensory,interval: 10s,retries: 5) has nostart_period, and neither doespgbouncer's. Every other service with a genuine cold-start delay in the same file was given an explicitstart_periodin the prior hardening pass (qdrant, ollama, browserless, rees, reporting-exporter, tempo, and the coregittensoryapp itself, whose comment explicitly says its 60sstart_period"tolerates the Postgres cold start"). Postgres — the one service furthest upstream in that dependency chain — was skipped.Docker's healthcheck state machine counts every failed probe toward
retriesfrom the very first check unlessstart_periodis set. On apgvector/pgvector:pg16image doing a genuinely coldinitdb(creating the pgvector extension, first-boot WAL setup) under real-world conditions (slow disk, low-memory VPS, first pull), 5 consecutive failures at a 10s cadence (~50s) is plausible. Once Docker marks postgresunhealthy,docker compose upfails thegittensory/pgbouncer/postgres-exporterdepends_on: condition: service_healthygates outright, rather than tolerating a slow-but-successful cold start.Requirements
start_period(e.g. 20-30s, matching the pattern used for qdrant/ollama/rees) to thepostgreshealthcheck.pgbouncer's healthcheck, which also lacks one and depends transitively on Postgres being genuinely ready.Acceptance criteria
docker compose upon a slow/first-pull host tolerates a realistic Postgresinitdbduration without failing dependent services' startup gates.Parent: #1667