[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org