[
https://issues.apache.org/jira/browse/CASSANDRA-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7120:
----------------------------------------
Attachment: 7120-alternative.txt
I don't think just copying the Metadata.names as the patch does works because
it loses the Metadata.columnCount which can be different from the names size
(due to CASSANDRA-4911 and more precisely following call to
Metadata#addNonSerializedColumn). We could add some clone() method that
preserve this, though I'd have a minor preference for saving the reallocation
of a Metadata object when no paging is involved (that's the common case and the
one we should optimize for). So attaching an aternative patch that makes the
paging state final and creates a new Metadata object when we need to attach a
paging state.
> Bad paging state returned for prepared statements for last page
> ---------------------------------------------------------------
>
> Key: CASSANDRA-7120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7120
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Tyler Hobbs
> Fix For: 2.1 rc1
>
> Attachments: 7120-alternative.txt, 7120.txt
>
>
> When executing a paged query with a prepared statement, a non-null paging
> state is sometimes being returned for the final page, causing an endless
> paging loop.
> Specifically, this is the schema being used:
> {noformat}
> CREATE KEYSPACE test3rf WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '3'}';
> USE test3rf;
> CREATE TABLE test3rf.test (
> k int PRIMARY KEY,
> v int
> )
> {noformat}
> The inserts are like so:
> {noformat}
> INSERT INTO test3rf.test (k, v) VALUES (?, 0)
> {noformat}
> With values from [0, 99] used for k.
> The query is {{SELECT * FROM test3rf.test}} with a fetch size of 3.
> The final page returns the row with k=3, and the paging state is
> {{0004000000420004000176007fffffa2}}. This matches the paging state from
> three pages earlier. When executing this with a non-prepared statement, no
> paging state is returned for this page.
> This problem doesn't happen with the 2.0 branch.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
