From 61c0b5bef45b7077c1e245e3f0d15e84fe1c86fd Mon Sep 17 00:00:00 2001 From: Aakash Kattelu Date: Wed, 5 Aug 2026 18:41:48 -0400 Subject: [PATCH] docs: clarify why docker compose avoids the pgvector privilege error The previous wording pinned the claim entirely on database/init.sql, which only runs on first boot of an empty data volume. The load-bearing reason is that the bundled stack connects as the postgres superuser, so it can create the extension regardless of volume state. Name that first and keep init.sql as the secondary reason. Co-Authored-By: Claude Opus 5 --- docs/v3/contributing/troubleshooting.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/v3/contributing/troubleshooting.mdx b/docs/v3/contributing/troubleshooting.mdx index 29748e2f..ffb73417 100644 --- a/docs/v3/contributing/troubleshooting.mdx +++ b/docs/v3/contributing/troubleshooting.mdx @@ -216,7 +216,7 @@ CREATE EXTENSION IF NOT EXISTS vector; The `IF NOT EXISTS` calls then short-circuit and the application role needs no extension privileges. This is the supported path for deployments where the platform, not the application, owns extension management. -You won't hit this with `docker compose` — the bundled database service runs `database/init.sql` as an initdb script, which creates the extension before Honcho ever connects. It comes up on managed Postgres, Kubernetes operators, and other setups where you bring your own database and its role is deliberately not a superuser. +You won't hit this with `docker compose` — the bundled stack connects as `postgres`, a superuser, and its database service also creates the extension from `database/init.sql` on first boot. It comes up on managed Postgres, Kubernetes operators, and other setups where you bring your own database and its role is deliberately not a superuser. ## Cache & Redis