On Mon, Feb 26, 2018 at 2:54 PM, Nadav Har'El wrote:
> When there are permanent inconsistencies though (when the base is
>
>> consistent and the view has extraneous rows), it doesn't really matter
>> if the inconsistency is present on a subset or all view replicas,
&
On Mon, Feb 26, 2018 at 2:54 PM, Nadav Har'El wrote:
> On Fri, Feb 23, 2018 at 12:49 AM, Paulo Motta
> wrote:
>
>> > Yes, it seems it will not be trivial. But if this is the common case in
>> common operations such as node addition or removal, it may significantly
On Fri, Feb 23, 2018 at 12:49 AM, Paulo Motta
wrote:
> > Is this a realistic case when Cassandra (unless I'm missing something) is
> limited to adding or removing a single node at a time? I'm sure this
> can happen under some sort of generic range movement of some
> sort (how does one initiate su
On Thu, Feb 22, 2018 at 12:54 AM, Paulo Motta
wrote:
>
> Good catch! This indeed seems to be a regression caused by
> CASSANDRA-13069, so I created CASSANDRA-14251 to restore the correct
> behavior.
>
I have a question about your patch
https://github.com/apache/cassandra/compare/trunk...pauloric
On Thu, Feb 22, 2018 at 12:54 AM, Paulo Motta
wrote:
> > 1. It seems that for example when RF=3, each one of the three base
> replicas will send a view update to the fourth "pending node". While this
> is not wrong, it's also inefficient - why send three copies of the same
> update? Wouldn't it b
some cases as I showed above, always), and needs to be handled
correctly, even if the cluster grows. If none of the base replicas will
send the view update to the pending node, it will end up missing this
update...
Thanks,
Nadav.
--
Nadav Har'El
n...@scylladb.com
