Segfault: postgres session + SET ROLE authenticated + call to a function with EXECUTE revoked (17.6.1.104 / 17.6.1.106)

Start with the minimal Docker reproduction using supabase/postgres:17.6.1.104 and the psql commands in the report, then compare the direct postgres plus SET ROLE path with the authenticator/PostgREST path. Investigate the function EXECUTE permission check and the listed shared_preload_libraries. Done means the denied call returns ERROR 42501 without a backend crash or cluster recovery.

Summary

On supabase/postgres:17.6.1.104 and 17.6.1.106, a session connected as the postgres role that does SET ROLE authenticated and then calls any function on which EXECUTE has been revoked from authenticated crashes the backend with signal 11 (Segmentation fault) instead of returning permission denied for function. The whole cluster goes into recovery for ~1 s.

It reproduces with a trivial select 1 function, LANGUAGE sql or plpgsql, scalar or set-returning, inside or outside a DO block, with SET ROLE or SET LOCAL ROLE.

It does not reproduce through the PostgREST path (authenticator → SET ROLE authenticated → call): that returns a clean ERROR: permission denied for function f. Permission errors on tables (RLS 42501, revoked TRUNCATE) do not crash either — only the function-EXECUTE denial from a postgres session does.

Minimal repro (bare image, no user data)

docker run --rm -d --name pgrepro -e POSTGRES_PASSWORD=postgres -p 54334:5432 supabase/postgres:17.6.1.104
# wait for pg_isready
docker exec pgrepro psql -U postgres -d postgres -c "
  create function public.f() returns int language sql as \$f\$ select 1 \$f\$;
  revoke execute on function public.f() from public, authenticated;"
docker exec pgrepro psql -U postgres -d postgres -c "set role authenticated; select public.f();"
#   server closed the connection unexpectedly
docker logs pgrepro 2>&1 | grep 'terminated by signal'
#   LOG:  server process (PID 238) was terminated by signal 11: Segmentation fault

Same result with supabase/postgres:17.6.1.106 (the image supabase start pins with CLI 2.90.0). Also reproduced inside a full supabase start stack.

show shared_preload_libraries in the image: pg_stat_statements, pgaudit, plpgsql, plpgsql_check, pg_cron, pg_net, pgsodium, auto_explain, pg_tle, plan_filter, supabase_vault.

Expected

ERROR: permission denied for function f (SQLSTATE 42501), as it happens via authenticator.

Why it matters

The postgres role is the one used by migration runners, CI test harnesses (psql as postgres + SET LOCAL ROLE authenticated to exercise RLS/grants) and the Supabase MCP execute_sql. A test that legitimately checks "authenticated cannot execute this function" takes the database down — in CI it kills the job; against a hosted project it would restart the primary. We hit it in CI first, then confirmed on both images. Postgres logs on our hosted project (same 17.6 line) show no segfaults, so the PostgREST/client path looks unaffected; we are only reporting the privileged-session path.

Happy to provide a core dump / more details if useful.