[
https://issues.apache.org/jira/browse/CASSANDRA-16223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220657#comment-17220657
]
Sylvain Lebresne commented on CASSANDRA-16223:
----------------------------------------------
bq. It does not impact 3.0.x because AFAIU there is no value skipping
optimization in 3.0.x.
It's true that the bug here does not manifest on 3.0. That said, the code is
still kind of wrong in 3.0 as well (range queries just don't get the proper
column filter for super columns), and while this may not manifest in a bug in
practice, it still feel a bit dodgy to leave as is in practice. Plus, fixing
{{ThriftIntegrationTest}} in 3.0 doesn't hurt either.
Anyway, I've pulled the patch against 3.0 as well (it applies without any
changes whatsoever) and started CI on both branches. Planning to commit both
when I get clean result from CI (unless someone object quickly on the 3.0 part).
|| patch || CI run ||
| [3.0|https://github.com/pcmanus/cassandra/commits/C-16223-3.0] |
[#133|https://ci-cassandra.apache.org/job/Cassandra-devbranch/133/] |
| [3.11|https://github.com/pcmanus/cassandra/commits/C-16223-3.11] |
[#134|https://ci-cassandra.apache.org/job/Cassandra-devbranch/134/] |
> Reading dense table yields invalid results in case of row scan queries
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-16223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16223
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ThriftIntegrationTest}} is broken in the way that it does not actually test
> reads before and after flushing, because it does not do flush at all (see
> https://github.com/apache/cassandra/blob/cassandra-3.11/test/unit/org/apache/cassandra/cql3/validation/ThriftIntegrationTest.java#L939).
> After fixing that method so that it really flushes memtables to disk, we can
> see inconsistency in reads from dense table - the results returned from
> memtable differs from the results returned from sstable (the later are wrong,
> cell values are skipped unexpectedly).
> {noformat}
> java.lang.AssertionError: Invalid value for row 0 column 0 (value of type
> ascii), expected <value1> but got <>
> {noformat}
> In principle this problems is about skipping column values when doing row
> scan queries with explicitly selected columns (not wildcard), when the
> columns belong to a super column. This happens only when reading from
> sstables, it does not happen when reading from memtables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
