Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with migrations for 0.12.0 #688

Closed
hypnoglow opened this issue Dec 6, 2024 · 6 comments · Fixed by #690
Closed

Problems with migrations for 0.12.0 #688

hypnoglow opened this issue Dec 6, 2024 · 6 comments · Fixed by #690

Comments

@hypnoglow
Copy link

CHANGELOG upgrade guide recommends running index migration manually for large tables. After that, "normal" river migration should be run to finalize the process.

The problem is that the existing index is tolerated, but the existing column is not, which results in the following error:

column "unique_states" of relation "river_job" already exists
@bgentry
Copy link
Contributor

bgentry commented Dec 6, 2024

@hypnoglow hmm, there wasn't a unique_states column prior to this migration v6. Did you perhaps try to run that migration line adding that column twice?

@hypnoglow
Copy link
Author

there wasn't a unique_states column prior to this migration v6

@bgentry You're right. But your migration guide suggests to run the following query to create it manually, because it is used in the index:

ALTER TABLE river_job ADD COLUMN unique_states BIT(8);

CREATE UNIQUE INDEX CONCURRENTLY river_job_unique_idx ON river_job (unique_key)
    WHERE unique_key IS NOT NULL
      AND unique_states IS NOT NULL
      AND river_job_state_in_bitmask(unique_states, state);

Then the guide recommends running river migrator, and so ALTER is executed second time.

@brandur
Copy link
Contributor

brandur commented Dec 12, 2024

@hypnoglow Ah yes that's quite right. We'll get a fix shipped for this immediately. Thanks for reporting!

brandur added a commit that referenced this issue Dec 12, 2024
As described in #688, if a user has followed changelog instructions to
create the new index concurrently, they will encounter an error as they
try to run the 006 migration to finalize it.

Here, tolerate the column already existing to fix the problem. An
existing index is already tolerated.

Fixes #688.
brandur added a commit that referenced this issue Dec 12, 2024
As described in #688, if a user has followed changelog instructions to
create the new index concurrently, they will encounter an error as they
try to run the 006 migration to finalize it.

Here, tolerate the column already existing to fix the problem. An
existing index is already tolerated.

Fixes #688.
brandur added a commit that referenced this issue Dec 14, 2024
As described in #688, if a user has followed changelog instructions to
create the new index concurrently, they will encounter an error as they
try to run the 006 migration to finalize it.

Here, tolerate the column already existing to fix the problem. An
existing index is already tolerated.

Fixes #688.
brandur added a commit that referenced this issue Dec 14, 2024
As described in #688, if a user has followed changelog instructions to
create the new index concurrently, they will encounter an error as they
try to run the 006 migration to finalize it.

Here, tolerate the column already existing to fix the problem. An
existing index is already tolerated.

Fixes #688.
@hypnoglow
Copy link
Author

Thank you 💙

tigrato pushed a commit to gravitational/river that referenced this issue Dec 18, 2024
…#690)

As described in riverqueue#688, if a user has followed changelog instructions to
create the new index concurrently, they will encounter an error as they
try to run the 006 migration to finalize it.

Here, tolerate the column already existing to fix the problem. An
existing index is already tolerated.

Fixes riverqueue#688.
@hypnoglow
Copy link
Author

Just FYI

In release descripion https://github.com/riverqueue/river/releases/tag/v0.14.3 PR links are mixed up with each other.

@bgentry
Copy link
Contributor

bgentry commented Dec 19, 2024

@hypnoglow thanks, fixed the GitHub release and will tweak the changelog too 🙏

brandur added a commit that referenced this issue Dec 19, 2024
Inverts links on #690 and #691 which currently point to each others pull
requests instead of their own, as reported in [1].

[1] #688 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants