Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Native stack engine: macOS runs out of shared memory segments after about 30 running stacks

Ouverte
#7,269 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
macos, postgresql, typescript
Domaine
cli, databases

Piste de recherche

Start by tracing the native stack startup path and how it handles Postgres startup failures, especially shmget errors; the issue does not name the relevant files or tests. The report describes three possible improvements: make the error actionable, stop idle Postgres instances, or clean up stacks for removed branches. Clarify which behavior is intended and how it should be verified before implementation.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

🐛 Bug supabase/cli

Summary

On macOS, the native stack engine runs out of System V shared memory segments once about 30 stacks are running, and supabase start then fails for every new checkout or branch.

What happens

The stack engine keeps one stack per checkout and branch, and a stack keeps running after its shell exits. Each running stack's Postgres creates a System V shared memory segment. macOS allows 32 segments on the whole machine by default (sysctl kern.sysv.shmmni prints 32), so with git worktrees and short-lived branches the limit is reached in a few days. ipcs -m shows the segments in use; on my machine 31 of 32 were taken before I stopped two stacks.

Steps to reproduce

  1. On macOS, set [experimental] stack = true in supabase/config.toml.
  2. Run supabase start --runtime native in about 30 worktrees or branches without stopping them.
  3. Run supabase start --runtime native in one more.

The last start fails because Postgres can't create its segment. supabase stack list shows the other stacks as reachable.

Environment

  • Supabase CLI 2.121.0, native runtime
  • macOS 26 (Darwin 25.6), Apple silicon
  • kern.sysv.shmmni: 32

Suggestions

  • Name the cause when Postgres fails on shmget, and point to supabase stack list and supabase stop --stack-id.
  • Stop the Postgres of a stack that has been idle for a while, the way the other services already stop when idle.
  • Offer a command that stops the stacks of branches that no longer exist or were merged. We use a small script for this today: it reads supabase stack list --output-format json, matches branch_context against git branch --merged main for the repo and its worktrees, and calls supabase stop --stack-id.
Langage dominant
TypeScript
Étoiles
2.4k
Forks
537
Merge moyen
17 h 22 min
PR mergées (30 j)
391

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de supabase/cli

Toutes les issues de supabase/cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.