[
https://issues.apache.org/jira/browse/CASSANDRA-19035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19035:
------------------------------------------
Description:
By adding a truncation record with the same timestamp a table is created we
will have a marker that says all the data for that table prior to its creation
should be considered stale.
That should be more concise and more efficient approach than requiring recycle
of all the commit log segments, which starts with flushing all dirty tables.
The scenario in question is when a user recreates a table with the same ID and
there is data in the commit log for that table, we may experience data
resurrection in that new table.
The performance improvement is probably quite minor for production use as users
usually do not drop tables that often. However it may positively impact our
tests which do quite many schema changes. It will also reduce significantly the
noise in the logs.
was:
By adding a truncation record with the same timestamp a table is created we
will have a marker that says all the data for that table prior to its creation
should be considered stale.
That should be more concise and more efficient approach than requiring recycle
of all the commit log segments, which starts with flushing all dirty tables.
The scenario in question is when a user recreates a table with the same ID and
there is data in the commit log for that table, we may experience data
resurrection in that new table.
> Consider adding a truncation record on table creation so that we can avoid
> force recycle on table drop
> ------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19035
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
>
> By adding a truncation record with the same timestamp a table is created we
> will have a marker that says all the data for that table prior to its
> creation should be considered stale.
> That should be more concise and more efficient approach than requiring
> recycle of all the commit log segments, which starts with flushing all dirty
> tables.
> The scenario in question is when a user recreates a table with the same ID
> and there is data in the commit log for that table, we may experience data
> resurrection in that new table.
> The performance improvement is probably quite minor for production use as
> users usually do not drop tables that often. However it may positively impact
> our tests which do quite many schema changes. It will also reduce
> significantly the noise in the logs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
