[
https://issues.apache.org/jira/browse/CASSANDRA-5153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558802#comment-13558802
]
Sylvain Lebresne commented on CASSANDRA-5153:
---------------------------------------------
I think the correct fix in LCR would be:
{noformat}
markedAt = emptyColumnFamily.getMarkedForDeleteAt();
maxTimestamp = reducer == null ? markedAt : Math.max(markedAt,
reducer.maxTimestampSeen);
{noformat}
because {{reducer == null}} implies there is no columns for that row in any of
the source SSTable, and thus guarantees we have a row tombstone (otherwise we
wouldn't have written the row in the first place). And in fact, even if we were
to write non-tombstoned empty rows, then MIN_VALUE would be the correct value
for maxTimestamp.
Also, while the default of MIN_VALUE for old non-timestamp-tracking sstables is
clearly bogus and should be fixed, I would almost suggest not bumping the
sstable version (I'm still hesitant but leaning towards not doing it). The
rational is that there are only 2 cases currently where a sstable can have a
MIN_VALUE max timestamp:
# the sstable is a pre-1.0.10 one that don't track timestamp. Fixing
SSTableMetada fixes that part.
# the sstable is entirely and uniquely composed of row tombstones.
The version bump is "fixing" only the latter but at the price of temporarly
breaking the collectTimeOrderedData optimization for everyone that will upgrade
to the version containing this. Granted collectTimeOrderedData is "just an
optimization", but having a sstable entirely composed of row tombstones is a
pretty remote risk. And besides, for it to trigger a problem you actually need
at least 2 sstables entirely composed of row tombstones (and even then there is
no guaranteed you'll get the bug). Feels even more than remote.
> max client timestamp
> --------------------
>
> Key: CASSANDRA-5153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5153
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.1
> Reporter: yangwei
> Assignee: Jonathan Ellis
> Fix For: 1.1.10, 1.2.1
>
> Attachments: 5153.txt
>
>
> 1. In public LazilyCompactedRow(CompactionController controller, List<?
> extends ICountableColumnIterator> rows)
> columnStats = new ColumnStats(reducer == null ? 0 : reducer.columns,
> reducer == null ? Long.MIN_VALUE : reducer.maxTimestampSeen,
> reducer == null ? new
> StreamingHistogram(SSTable.TOMBSTONE_HISTOGRAM_BIN_SIZE) : reducer.tombstones
> Tthe maxTimestampSeen should be
> max(emptyColumnFamily.deletionInfo().maxTimestamp(),
> reducer.maxTimestampSeen)?
> 2. In private ColumnFamily collectTimeOrderedData()
> // if we've already seen a row tombstone with a timestamp
> greater
> // than the most recent update to this sstable, we're done,
> since the rest of the sstables
> // will also be older
> if (sstable.getMaxTimestamp() < mostRecentRowTombstone)
> break;
> In the case that sstable.getMaxTimestamp == Long.MIN_VALUE, is it logical?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
