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.
Hi, I'd like to have
--skip-drop-table
option by default. For dropping,--drop-table
.#105 proposed about this, but looks not discussed.
For Data safety
Obviously, resulting tail risk differs between default options.
--skip-drop-table
causes permanent DATA LOST.--drop-table
requires just rerun.For Table Partitioning
I tested Table Partitioning on PostgreSQL.
With
--skip-drop-table
option, ridgepole works mostly well.Table Partitioning has multiple tables called "partitions" that actual data resides.
Partitions schema derives from a single abstruct "partitioned table", so ridgepole doesn't have chance to migrate "partitions".
With
--skip-drop-table
, we can migrate "partitioned table" as just plain tables and then followed by its partitions.(I don't mean that ridgepole can migrate a plain table into a partitioned table. It requires manual operations anyway.)
With partitioning, we have many arbitrary partitions, which faces DATA LOST risk with current ridgepole default behavior.
Table partitioning is just a case, and we will have situations that ridgepole should let several tables go.