Remove active column

[arpad-m]

We don't need or want the active column. Remove it. Vlad pointed out that this is safe.

Thanks to the separation of the schemata in earlier PRs, this is easy.

follow-up of #10205

Part of #9981

[github-actions]

7293 tests run: 6928 passed, 0 failed, 365 skipped (full report)

---

Flaky tests (3)

Postgres 17

• test_timeline_archival_chaos: release-x86-64

Postgres 15

• test_parallel_copy: release-arm64

Postgres 14

• test_physical_replication_config_mismatch_max_locks_per_transaction: release-x86-64

Code coverage* (full report)

• functions: 32.5% (8037 of 24737 functions)
• lines: 47.8% (66772 of 139809 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
78b4727 at 2025-01-10T00:44:32.251Z :recycle:}

[VladLazar]

LGTM - can you please check that the following scenario is okay as long as we don't query the safekeepers or add a new one:

1. new storage controller is released
2. We roll-back the storage release
3. old storage controller starts-up

[arssher]

It should be safe, no active code is reading safekeepers from the db yet.

[arpad-m]

Yeah we don't use the column for anything, nor do we read from the db as part of routine operation, so I think it should be safe. Going to merge this PR once #10338 merges.

We don't have the roll-back of migrations as part of the release workflow yet, right? Aka, "rollback" of a release is just rolling out the old one. I think this is not sufficient here as the "down" migration is not present in the older release.

If we want to do a rollback, we'd need to manually apply the right sql commands during the release process.

[VladLazar]

We don't have the roll-back of migrations as part of the release workflow yet, right? Aka, "rollback" of a release is just rolling out the old one. I think this is not sufficient here as the "down" migration is not present in the older release.

If we want to do a rollback, we'd need to manually apply the right sql commands during the release process.

Right. I was thinking about: "do we have to do the manual db rollback as long as we dont't query the safekeepers table?". I think we don't have to.