Details
-
Task
-
Status: Open
-
Normal
-
Resolution: Unresolved
-
None
-
Quality Assurance
-
Challenging
-
All
-
None
Description
ALTER ... DROP COMPACT STORAGE statements have not been extensively tested and suffer from several issues like:
- As COMPACT tables did not have primary key liveness there empty rows
inserted AFTER the ALTER will be returned whereas the one inserted before
the ALTER will not. - Also due to the lack of primary key liveness the amount of SSTables being
read will increase resulting in slower queries (CASSANDRA-16675) - After DROP COMPACT it becomes possible to ALTER the table in a way that
makes all the row disappears - There is a loss of functionality around null clustering when dropping
compact storage (CASSANDRA-16069)
To avoid running into those issues, CASSANDRA-16733 introduced a new flag that allows operators to disable those statements on their clusters and pointed out that ALTER ... DROP COMPACT STORAGE is not production-ready.
see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
This ticket should facilitate outlining and implementing a plan how to make ALTER ... DROP COMPACT STORAGE production-ready and revert the patch from CASSANDRA-16217.
Attachments
Issue Links
- is related to
-
CASSANDRA-19291 Fix NEWS.txt Compact Storage section
- Resolved