[
https://issues.apache.org/jira/browse/CASSANDRA-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-13793.
------------------------------------------
Resolution: Invalid
Ignore me, I'm a moron, I jumped to conclusion without properly reading the
code. The code from 3.0 does properly set collection tombstones to {{t - 1}}.
There does seem to be a small behavior difference around this code between 2.1
and 3.0 in that 2.1 was using {{t}} for cell tombstones while 3.0 is now using
{{t - 1}} but that's unrelated to what I wrote above so closing that.
> Regression in 3.0, breaking the fix from CASSANDRA-6069
> -------------------------------------------------------
>
> Key: CASSANDRA-13793
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13793
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> The goal of the fix of CASSANDRA-6069 was to make sure that collection
> tombstones in an update in CAS were using {{t-1}} because at least in
> {{INSERT}} collection tombstones are used to delete data prior to the update
> but shouldn't delete the newly inserted data itself. Because in 2.x the
> collection tombstones are normal range tombstones and thus part of the
> {{DeletionInfo}}, we went with the easy solution of using {{t-1}} for all of
> {{DeletionInfo}}.
> When moving that code to 3.0, this was migrated too literally however and
> only the {{DeletionInfo}} got the {{t -1}}. But in 3.0, range tombstones are
> not part of {{DeletionInfo}} anymore, and so this is broken.
> Thanks to [~aweisberg] for noticing this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
