Native stack engine: macOS runs out of shared memory segments after about 30 running stacks
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- macos, postgresql, typescript
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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
- On macOS, set
[experimental] stack = trueinsupabase/config.toml. - Run
supabase start --runtime nativein about 30 worktrees or branches without stopping them. - Run
supabase start --runtime nativein 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 tosupabase stack listandsupabase 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, matchesbranch_contextagainstgit branch --merged mainfor the repo and its worktrees, and callssupabase stop --stack-id.
- 主要语言
- TypeScript
- 星标
- 2.4k
- 派生
- 540
- 平均合并
- 17 小时 29 分钟
- 30 天内合并 PR
- 387
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
supabase/cli 的其他 Issue
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructive可能重新可做 关联的 PR 已关闭且未合并。 未关闭✨ Feature supabase/cli
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
`supabase start` waits about 10 seconds for Docker's first health check after services are ready未关闭🐛 Bug supabase/cli
难度 3/5 1-2 天 新手友好度 70/100
维护者通常 1 天内回复
-
🐛 Bug supabase/cli
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
-
stack: every Edge Function request starts a new worker, so the same function never reuses one and each call pays a cold start可能已有人在做 @7ttp 于 4 天前认领。 未关闭🐛 Bug supabase/cli
难度 3/5 1-2 天 新手友好度 58/100
维护者通常 1 天内回复
-
Explicit local function bundling falls back to API bundling when Docker is unavailable可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭🐛 Bug open-for-contribution supabase/cli
难度 3/5 1-2 天 新手友好度 68/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
Slaymish/HealthAgent#7 ·
-
area: engine topic: math type: bug
难度 2/5 1-3 小时 新手友好度 80/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 70/100
Get-Concord-AI/concord-mcp#310 ·
维护者通常 1 天内回复
-
Correct install_claude: 'marketplace add' over a different source is refused, not replaced in place未关闭type:bug
难度 2/5 1-3 小时 新手友好度 80/100
nightgauge/nightgauge#2804 ·
维护者通常 1 天内回复