sequences: advance them alone, by a million, and check there is room - #2
Merged
Conversation
The cutover's sequence step is now a command of its own, for a migration that moves traffic before it moves the database. It reads each selected sequence's next value on the source and sets the target's copy that far past it. Values are set absolutely rather than advanced, so running it again is harmless and the cutover redoes it against the source's final values. The gap it leaves is a million rather than a thousand. That gap is the only thing between what the source allocates while it is still serving and a key the target has already handed out, and a thousand of them is a few seconds of a busy table. A gap that size makes a sequence running out of room a real failure mode, so preflight reports one now. Less room left than --sequence-offset is an error: setval refuses a value past the bound, so the cutover would fail at its sequence step no matter how willing the operator is. Under ten million values left is a warning, because how much is enough depends on how fast the application allocates and how long the source keeps serving, which only the operator knows. Only the sequences the cutover will set are considered, and the headroom arithmetic is unsigned: sequence bounds span the whole of int64, and subtracting two of them as signed values overflows and reports a sequence with room to spare as exhausted. Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pgmigrate sequencesruns the cutover's sequence step on its own, fromfollowonwards, for a migration that moves traffic before it moves the database. Values are set absolutely, so rerunning it and the cutover after it are both harmless.--sequence-offsetdefaults to 1,000,000 rather than 1,000. That gap is the only thing between what the source allocates while it is still serving and a key the target has already handed out. The zero fallback insidecutover.Runis gone, so the flag is the only default and--sequence-offset 0means no gap.--sequence-offset, becausesetvalrefuses a value past the bound and the cutover would fail at its sequence step, and a warning under 10,000,000 values. Only the sequences the cutover will set are considered, meaning those a selected table owns or draws a column default from.Test plan
gofmt -l .,go vet ./...,go test ./...go test -tags integration ./internal/preflight/including the newTestPG17SequenceHeadroom, which checks that the error blocks, the warning is acknowledgeable, the recommendedALTER SEQUENCE ... MAXVALUEclears the error, and unselected sequences stay unreportedgo test -tags integration ./internal/cutover/, with the descending fixture widened so a million-value bump stays in boundsmake e2e:data-correctness=ok,migration-e2e=ok, and the report recordssequence_offset: 1000000withorder_id_seqset from 1149 to 1001149Made with Cursor