Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

`supabase/postgres:17.6.1.105` (amd64) — backend SIGSEGV during a heavy pgTAP file, CI-CPU-specific

Abierto
  • ¿Algo no está bien?
#2,467 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
docker, github-actions, postgresql
Área
ci-cd, databases, testing-qa

Línea de trabajo

Comienza ejecutando el archivo pgTAP completo y autocontenido contra public.ecr.aws/supabase/postgres:17.6.1.105 en un runner amd64 de GitHub Actions con capacidad AVX-512, usando la configuración de PGOPTIONS indicada. Recopila los datos de lscpu del runner y un backend core o backtrace; después determina si el fallo está relacionado con la compilación de la imagen o con la ruta de dispatch. Se considera completado cuando se confirma un fallo o se obtiene un caso reducido reproducible con una mitigación documentada.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

The amd64 public.ecr.aws/supabase/postgres:17.6.1.105 image deterministically SIGSEGVs a backend process (signal 11) while running one large single-transaction pgTAP test file — but only on GitHub Actions ubuntu-latest runners. The byte-identical image on a local amd64 workstation (Intel i7-8850H, AVX2) runs the same file cleanly every time, and our aarch64 production build is unaffected. This points to a CPU-microarchitecture-dependent code path in the amd64 17.6.1.105 build (the runner CPU is AVX-512-capable; our local CPU is not — AVX-512 is our leading hypothesis but is not core-dump-confirmed).

Environment

Image / build CPU Result
GitHub Actions ubuntu-latest public.ecr.aws/supabase/postgres:17.6.1.105 (amd64) AVX-512-capable x86_64 (Xeon/EPYC-class) SIGSEGV, 6/6 runs
Local workstation same image (amd64) Intel i7-8850H (AVX2, no AVX-512) clean, every run
Supabase production aarch64 build — PostgreSQL 17.6 on aarch64-unknown-linux-gnu ARM64 clean
  • Local version(): PostgreSQL 17.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 15.2.0, 64-bit
  • Invocation: docker exec -i supabase_db_<project> psql -U postgres -d postgres -v ON_ERROR_STOP=1 < <file>.sql (Supabase CLI local stack; the file runs inside one BEGIN … ROLLBACK).

Observed behavior

A single pgTAP file (plan(363), ~4300 lines, one long transaction in one backend) crashes the backend mid-run:

LOG:  server process (PID …) was terminated by signal 11: Segmentation fault
LOG:  terminating any other active server connections
… database system is in recovery mode

The cluster then enters recovery and takes down the sibling test files running after it.

What it is NOT (ruled out with evidence)

  • Not OOM — signal 11 (not 9); dmesg is empty; adding swap did not help.
  • Not JIT — jit=off set per-connection via PGOPTIONS (verified active via SHOW jit); still crashed.
  • Not the outer plan shape — forcing plans with GUCs (enable_bitmapscan/hashagg/hashjoin=off, max_parallel_workers_per_gather=0) did not change the crash.
  • Not the SQL of the crashing statement — the crash lands on a statement (SELECT * FROM a SECURITY DEFINER SETOF-uuid helper) invoked by a role whose EXECUTE on that function is revoked, so it errors 42501 at the ACL check before the function body runs. The identical call by a privileged role earlier in the same file (and the same query shape ~17× before) runs clean. So the fault is not inside that function's execution — it is a delayed manifestation of state accumulated earlier in the backend.

The accumulation that appears to trigger it

The file, in one long-lived backend, builds up an unusually heavy load before the crash: hundreds of set_eq / EXCEPT-based pgTAP assertions (each materializing temp result sets), a BYPASSRLS role, and repeated trigger DDL / RLS-policy evaluation, all in one transaction. The corruption seems laid down by that accumulation and surfaces one statement later. On a fresh backend (e.g. splitting the file so the tail runs in its own psql/backend) the crash locus changes — consistent with private-backend-memory corruption rather than a specific query.

Reproduction

The full test file is self-contained pgTAP and reproduces 6/6 on an AVX-512-capable amd64 runner. We do not yet have a reduced repro (bisecting requires iterating on the AVX-512 hardware, which we only have via CI). We can share the full file privately, or work with you on a minimal case. To attempt repro:

  1. supabase start (or run public.ecr.aws/supabase/postgres:17.6.1.105 directly) on an AVX-512-capable amd64 host.
  2. Apply a schema with RLS + a SECURITY DEFINER set-returning helper, then run a long single-transaction pgTAP file that accumulates several hundred set_eq/EXCEPT assertions + a BYPASSRLS role + trigger DDL.
  3. Observe the backend SIGSEGV partway through.

A build compiled -O2 with CPU-dispatched SIMD (or a gcc 15.2.0 codegen issue on AVX-512) is the working hypothesis; a backtrace/core from the crashing backend on the runner would confirm the faulting routine.

Impact & current workaround

  • We have quarantined the one file from CI and gated it locally on AVX2; all other tests pass. No production impact — production is aarch64 (a different build with no x86 SIMD path), and the helper executes correctly there.
  • Asking here because it is your image build: a fix in the amd64 17.6.1.x build would let everyone re-enable such tests on standard CI runners.

Questions

  1. Is a SIGSEGV in the 17.6.1.105 amd64 build on AVX-512 hardware a known issue?
  2. Any recommended mitigation short of pinning an older/newer 17.x image (a build flag, a disabled dispatch path)?
  3. Would a full repro file + a runner lscpu be useful, or do you want a reduced case first?
Lenguaje dominante
Nix
Estrellas
1.8k
Forks
267
Merge medio
1 d 20 h
PR fusionados (30 d)
32

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de supabase/postgres

Todos los issues de supabase/postgres

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.