Uh oh!
There was an error while loading. Please reload this page.
fix(db): raise maintenance_work_mem in the migration runner - #511
Conversation
Applying the reconciled backlog to staging died seven files in: ProgramLimitExceeded: memory required is 35 MB, maintenance_work_mem is 32 MB 0039_rag_vector_store builds an ivfflat index over VECTOR(768). Supabase defaults maintenance_work_mem to 32 MB, so the build cannot complete — and because apply_migration wraps each file plus its ledger INSERT in one transaction and run() has no per-file recovery, it took the remaining four migrations down with it. The ledger stopped at 44 of 49 with no partial state, which is the one good thing about that failure mode. This is not staging-specific. Any environment on the default hits it the first time 0039 runs, prod included, and prod has not been migrated yet. Set per session, not per environment. `ALTER DATABASE ... SET` only reaches backends started after it, and a pooled connection is frequently already established — observed directly against Supavisor, where a fresh backend picked up the new value while a reused one still reported 32 MB, making the change look like it had silently failed. A session-level SET always lands on the connection actually running the DDL. 128 MB is transient per-operation memory during an index build, not a reservation, and leaves headroom over 0039's ~35 MB without being reckless on a small instance. MIGRATE_MAINTENANCE_WORK_MEM overrides it. The SET is a literal rather than a bound parameter because SET does not accept one; the value is operator config, never request input, and a bad value fails loudly at the start instead of mid-migration. Verified by using it: staging's remaining 5 migrations applied cleanly, and the drift report now reports 49 on disk / 49 recorded / 0 pending / 0 orphans, exit 0. That also closed#316 (avatars bucket now public=true) and #265 (assignments_source_check now admits 'gradescope'). 1557 passed, 38 skipped; ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reached
Next review available in:12 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying with |
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs | frontend-staging | 9218ad8 | Commit Preview URL Branch Preview URL | Aug 01 2026, 07:08 AM |
Uh oh!
There was an error while loading. Please reload this page.
Applying the reconciled backlog (#510) to staging died seven files in:
0039_rag_vector_storebuilds an ivfflat index overVECTOR(768). Supabase defaultsmaintenance_work_memto 32 MB, so the build cannot complete — and becauseapply_migrationwraps each file plus its ledger INSERT in one transaction andrun()has no per-file recovery, it took the remaining four migrations down with it. The ledger stopped cleanly at 44 of 49 with no partial state, which is the one merciful thing about that failure mode.This is not staging-specific. Any environment on the default hits it the first time 0039 runs — prod included, and prod has not been migrated yet.
Why per-session rather than per-environment
ALTER DATABASE ... SETonly reaches backends started after it, and a pooled connection is frequently already established. Observed directly against Supavisor: a fresh backend picked up the new value while a reused one still reported 32 MB, which makes the change look like it silently did nothing. A session-levelSETalways lands on the connection actually running the DDL.128 MB is transient per-operation memory during an index build, not a reservation, and leaves headroom over 0039's ~35 MB without being reckless on a small instance.
MIGRATE_MAINTENANCE_WORK_MEMoverrides it.The value is interpolated as a literal because
SETdoes not accept a bound parameter. It is operator config, never request input, and a bad value fails loudly at the start rather than mid-migration.Verification
Verified by using it — staging's remaining 5 migrations applied cleanly:
That also closed#316 (
avatarsbucket nowpublic=true) and #265 (assignments_source_checknow admits'gradescope').1557 passed, 38 skipped;
ruff checkclean.🤖 Generated with Claude Code