Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,212 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
docker, postgresql
Ambito
databases

Direzione di ricerca

Inizia riproducendo il carico di lavoro misto e concorrente con Supabase CLI 2.101.0 e l’immagine supabase/postgres:17.6.1.111, quindi ispeziona docker logs per il signal 11 ripetuto e l’istruzione fallita del wrapper PostgREST che coinvolge json_to_record, json_agg e LATERAL. Il lavoro è completato quando sono stati ottenuti una riproduzione pubblica minima e l’identificazione di una causa di PostgreSQL o del binario pacchettizzato che, con questo carico di lavoro, non produca più segfault del backend.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
  • 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.

Lingua principale
Nix
Stelle
1.8k
Fork
268
Merge medio
3g 22h
PR unite (30g)
44

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di supabase/postgres

Tutte le issue di supabase/postgres

Issue simili

Altre issue su Databases

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.