[
https://issues.apache.org/jira/browse/CASSANDRA-14251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14251:
------------------------------------
Reproduced In: 3.11.1, 3.0.15 (was: 3.0.15, 3.11.1)
Status: Patch Available (was: Open)
Added regression
[dtest|https://github.com/pauloricardomg/cassandra-dtest/commit/dbf6eba59da67edaa50930046fc440430fe61d2d]
and
[restored|https://github.com/pauloricardomg/cassandra/commit/1a06c97a7896621f346b806e6369a820b75fdd75]
correct behavior along with a NEWS.txt asking MV users potentially affected by
this to run repair on the view to ensure all replicas are up to date.
||3.0||3.11||trunk||dtest||
|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-14251]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.11...pauloricardomg:3.11-14251]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-14251]|[branch|https://github.com/apache/cassandra-dtest/compare/master...pauloricardomg:14251]|
Will run internal CI and post results here when ready.
> View replica is not written to pending endpoint when base replica is also
> view replica
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14251
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14251
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
> Reporter: Paulo Motta
> Assignee: Paulo Motta
> Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> From the [dev
> list|https://www.mail-archive.com/[email protected]/msg12084.html]:
> bq. There's an optimization that when we're lucky enough that the paired view
> replica is the same as this base replica, mutateMV doesn't use the normal
> view-mutation-sending code (wrapViewBatchResponseHandler) and just writes the
> mutation locally. In particular, in this case we do NOT write to the pending
> node (unless I'm missing something). But, sometimes all replicas will be
> paired with themselves - this can happen for example when number of nodes is
> equal to RF, or when the base and view table have the same partition keys
> (but different clustering keys). In this case, it seems the pending node will
> not be written at all...
> This was a regression from CASSANDRA-13069 and the original behavior should
> be restored.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
