[
https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994643#comment-15994643
]
Duarte Nunes commented on CASSANDRA-13409:
------------------------------------------
Why not?
You can have (base pk on p and view's pk is on v1 and p, assume flushes between
operations):
1. insert into base (p, v1, v2) values (3, 1, 3) using timestamp 1
2. update base set v2 = null where p = 3 using timestamp 2 // deletes a cell
3. update base set v1 = 2 where p = 3 using timestamp 3 // will create a
shadowable row tombstone for (v1, p) = (1, 3)
4. update base set v1 = 1 where p = 3 using timestamp 4
Here you have a deleted cell co-existing with a shadowable tombstone. The
problem is then that the view updates for 2) and 3) can be compacted together,
and the tombstone for v2 will be dropped, leaving only the shadowable row
tombstone. After the view update in 4), assuming it's done after gc grace
seconds, the row tombstone will be shadowed and the update for v2 made in 1)
will be resurrected.
You can have a similar sequence of events involving row tombstones:
1. insert into base (p, v1, v2) values (3, 1, 3) using timestamp 1
2. delete from base where p = 3 using timestamp 2 // will create a regular row
tombstone for (v1, p) = (1, 3)
3. insert into base (p, v1) values (3, 1) using timestamp 3
4. update base set v1 = 2 where p = 3 using timestamp 4 // will create a
shadowable row tombstone for (v1, p) = (1, 3)
5. update base set v1 = 1 where p = 3 using timestamp 5
Here, if the sstables with 2) and 4) are compacted together, the shadowable
tombstone will cover and remove the regular one.
The same partition can easily contain regular and shadowable tombstones, so
that should be taken into account when merging rows in memory.
> Materialized Views: View cells are resurrected
> ----------------------------------------------
>
> Key: CASSANDRA-13409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
> Reporter: Duarte Nunes
> Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk@0f054fee5c:
> {code:xml}
> echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};" | bin/cqlsh
> echo "create table ks.base (p int primary key, v1 int, v2 int) with
> gc_grace_seconds = 1;" | bin/cqlsh
> echo "create materialized view ks.my_view as select * from ks.base where p is
> not null and v1 is not null primary key (v1, p);" | bin/cqlsh
> echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" |
> bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "select * from ks.my_view;" | bin/cqlsh
> v1 | p | v2
> ----+---+----
> 1 | 3 | 3
> (1 rows)
> echo "select * from ks.base;" | bin/cqlsh
> p | v1 | v2
> ---+----+------
> 3 | 1 | null
> (1 rows)
> {code}
> As you can see, this incorrectly brings back cell v2=3.
> There is one definitive problem and a potential one:
> * Merging rows must be commutative. If a shadowable tombstone is applied
> after a row tombstone, it will replace that tombstone; if a row marker
> shadows the shadowable tombstone before the row containing the original data
> is applied, then any dead cells in said data will be resurrected;
> * Shadowable tombstones shouldn't compact away previous row tombstones or
> even deleted cells; if the relevant tombstones have been GCed from the base
> table, then a base table update won't carry them anymore (alongside a newer
> row marker).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
