cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-13793) Regression in 3.0, breaking the fix from CASSANDRA-6069
Date Thu, 24 Aug 2017 10:08:00 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message