From 499b8448d9b45fe80fae5f73608db9a8a8df2297 Mon Sep 17 00:00:00 2001 From: Eric Hare Date: Wed, 10 Jun 2026 10:01:23 -0700 Subject: [PATCH] docs: update postgis relocation runbook with verified prod state MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Live state of qijajhckwxsclvyzeaez checked via the Supabase MCP: PostGIS 3.3.7 in public owned by supabase_admin, postgres not superuser, and all anon/authenticated grants on spatial_ref_sys have grantor supabase_admin — confirming both self-service paths (in-place relocation, REVOKE) are dead ends and the support ticket is the only non-destructive option. Corrects the ticket SQL to the version Supabase's troubleshooting section prescribes for 3.3.7 (UPDATE TO "3.3.7next"; "ANY" only exists on >= 3.5, which is what our CI validation used). Also records that relocation clears six additional advisor WARNs (0028/0029 on public.st_estimatedextent, a SECURITY DEFINER postgis function exposed at /rest/v1/rpc) beyond 0013/0014. --- docs/POSTGIS-SCHEMA-RELOCATION.md | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/docs/POSTGIS-SCHEMA-RELOCATION.md b/docs/POSTGIS-SCHEMA-RELOCATION.md index d34750a..77b31ae 100644 --- a/docs/POSTGIS-SCHEMA-RELOCATION.md +++ b/docs/POSTGIS-SCHEMA-RELOCATION.md @@ -1,15 +1,24 @@ # Relocating PostGIS out of `public` **Status:** migration `20260610_1000` shipped; prod (Supabase) step pending a -support ticket. +support ticket. Live prod state verified 2026-06-10 via the Supabase MCP: +PostGIS **3.3.7** in `public`, owned by `supabase_admin`; `postgres` is not +superuser (`rolsuper = false`); every `anon`/`authenticated` grant on +`spatial_ref_sys` has grantor `supabase_admin`, so a `REVOKE` as `postgres` +is a silent no-op — both self-service paths are confirmed dead ends. ## Problem -The Supabase security advisor flags two findings on project -`qijajhckwxsclvyzeaez`: +The Supabase security advisor flags these findings on project +`qijajhckwxsclvyzeaez`, all caused by postgis living in `public`: -- `rls_disabled_in_public` (0013) on `public.spatial_ref_sys` -- `extension_in_public` (0014) on `postgis` +- `rls_disabled_in_public` (0013, ERROR) on `public.spatial_ref_sys` +- `extension_in_public` (0014, WARN) on `postgis` +- `anon_security_definer_function_executable` (0028, WARN) ×3 and + `authenticated_security_definer_function_executable` (0029, WARN) ×3 on + `public.st_estimatedextent(…)` — a postgis SECURITY DEFINER function + exposed at `/rest/v1/rpc/st_estimatedextent` because it sits in the + exposed schema. Relocation clears all of these at once. `spatial_ref_sys` is a lookup table owned by the PostGIS extension (created as `supabase_admin` on Supabase). The `postgres` role cannot `ALTER TABLE … @@ -35,12 +44,18 @@ reproduce in their Troubleshooting section: BEGIN; UPDATE pg_extension SET extrelocatable = true WHERE extname = 'postgis'; ALTER EXTENSION postgis SET SCHEMA extensions; -ALTER EXTENSION postgis UPDATE TO "ANY"; -- "next" on PostGIS <= 3.2 -ALTER EXTENSION postgis UPDATE; -- dummy upgrade rewrites internal refs +ALTER EXTENSION postgis UPDATE TO "3.3.7next"; -- prod is 3.3.7; use "ANY" on >= 3.5 +ALTER EXTENSION postgis UPDATE; -- dummy upgrade rewrites internal refs UPDATE pg_extension SET extrelocatable = false WHERE extname = 'postgis'; COMMIT; ``` +The version-suffix form (`"next"`) is what Supabase's own +troubleshooting section prescribes; our CI/local validation on 3.5.2 used +`"ANY"`, which only exists on newer PostGIS. Prod's installed version is +3.3.7 (verified) — if Supabase has upgraded it by ticket time, re-check with +`SELECT extversion FROM pg_extension WHERE extname = 'postgis'`. + This needs **superuser** (it writes `pg_catalog`). On Supabase, `postgres` is not a superuser and the extension is owned by `supabase_admin`, so Supabase's documented path for an existing project is: *contact Supabase support and ask