PG 17.6 (supabase/postgres 17.6.1.111) backend SIGSEGV under mixed concurrent load executing a PostgREST jsonb RPC wrapper

[iaconsultores]

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Under a mixed concurrent workload against the local stack, a Postgres
backend repeatedly dies with signal 11 (Segmentation fault) and the
postmaster enters crash recovery (~8-10 s). Typically 3 crashes per test
run, reproducible across fresh stacks. The crashing statement is ALWAYS
the same: the PostgREST-generated wrapper for one of our RPCs
(jsonb-heavy: json_to_record + json_agg + LATERAL). Five
single-variable A/B experiments (each lever verified active on an
authenticator session before measuring) all crash identically, which
points at the packaged binary rather than configuration or application
code.

To Reproduce

We could not reduce it to a minimal public repro yet — the crash needs
the full mixed workload (private test suite); concurrent calls to the
RPC alone, or combined with concurrent signups, do NOT crash. Workload
shape that reproduces it reliably (3 crashes/run):

1. supabase start (CLI 2.101.0) + supabase db reset on a schema with
   an AFTER-INSERT trigger on signup that clones ~702 rows per new user.
2. Run a Vitest suite (sequential files) mixing: bursts of
   auth.admin.createUser (~20), SECURITY DEFINER journal-entry RPCs,
   and repeated calls to a jsonb-taking RPC (upsert_form_draft) via
   PostgREST with user JWTs.
3. Watch docker logs supabase_db: signal 11 followed by "all server
   processes terminated; reinitializing" appears ~3 times per run,
   always with the same failed statement (below).

A concurrent-load hammer script for the RPC is available on request.

Expected behavior

No backend segfault under concurrent load; worst case a normal SQL
error, never signal 11 + cluster-wide crash recovery.

Screenshots

Log excerpt (identical across occurrences):

LOG:  server process (PID ...) was terminated by signal 11: Segmentation fault
DETAIL:  Failed process was running: WITH pgrst_source AS (
  SELECT pgrst_call.* FROM (SELECT $1 AS json_data) pgrst_payload,
  LATERAL (SELECT ... FROM json_to_record(pgrst_payload.json_data)
           AS _(... "p_payload" jsonb ...) LIMIT 1) pgrst_body,
  LATERAL "public"."upsert_form_draft"(...) pgrst_call )
  SELECT ..., coalesce(json_agg(_postgrest_t)->0, 'null') AS body, ...
LOG:  all server processes terminated; reinitializing
FATAL: the database system is in recovery mode

System information

• OS: Windows 11 + Docker Desktop (WSL2 VM: 12 CPU / 7.56 GiB)
• Browser: N/A (server-side; Vitest + PostgREST)
• Version of supabase-js: 2.105.1
• Version of Node.js: v24.15.0
• Supabase CLI: 2.101.0 · image supabase/postgres:17.6.1.111 →
  PostgreSQL 17.6, compiled by gcc 15.2.0 · PostgREST v14.5 ·
  GoTrue v2.189.0
• Settings: shared_buffers 128MB · work_mem 4MB · jit=on (llvmjit) ·
  max_parallel_workers_per_gather=2

Additional context

Ruled out by single-variable A/B (each lever verified active; all
crash identically — 3 signal 11 per run):

Lever	How applied
jit = off	ALTER DATABASE/SYSTEM + PostgREST pool reconnect (verified PostgREST's preamble does not reset jit)
max_parallel_workers_per_gather = 0	ALTER DATABASE + db restart
pg_stat_statements removed from shared_preload_libraries	direct auto.conf edit
plan_filter removed from shared_preload_libraries	direct auto.conf edit
CLI 2.101 → 2.106	image is byte-identical (17.6.1.111), so the bump cannot affect it

Not resource starvation: 33/100 connections, /dev/shm at 2%, ~5.2 GB
free in the VM. The trigger-cloned table has no exotic column types
(uuid/varchar/text/bool/timestamptz). Logflare logical replication
(publication logflare_pub) is active and appears interleaved with
the crashes in the log. Working hypothesis: a miscompilation in the
jsonb expression path given the gcc 15.2.0 build of PG 17.6.