Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      I noticed an inconsistent behavior on deletes. Not sure if it is intentional.

      The summary is:

      If a table is created with TTL or if rows are inserted in a table using TTL, when its time to expire the row, tombstone is generated (as expected) and cfstats, cqlsh tracing and sstable2json show it.

      However, if one executes a delete from table query followed by a select *, neither cql tracing nor cfstats shows a tombstone being present. However, sstable2json shows a tombstone.

      Is this situation treated differently on purpose ? In such a situation, does Cassandra not have to scan tombstones (seems odd) ?

      Also as a data point, if one executes a delete <some-column> from table, cqlsh tracing, nodetool cfstats, and sstable2json all show a consistent result (tombstone being present).

      As a end user, I'd assume that deleting a row either via TTL or explicitly should show me a tombstone. Is this expectation reasonable ? If not, can this behavior be clearly documented ?

        Activity

        Hide
        anubhavk Anubhav Kale added a comment -

        Any thoughts on this ?

        Show
        anubhavk Anubhav Kale added a comment - Any thoughts on this ?
        Hide
        slebresne Sylvain Lebresne added a comment -

        This is mostly a logging problem, namely that we don't log range tombstones in the trace (and in cfstats). That is, when the row is deleted, it generates a range tombstone while it generates cell tombstones with TTL, which is why it shows up in tracing/cfstats in the latter case but not in the former.

        It's something we certainly should fix (though at least in tracing we might want to log RT separately) but it doesn't have other consequences than being confusing when you look at traces/cfstats.

        Show
        slebresne Sylvain Lebresne added a comment - This is mostly a logging problem, namely that we don't log range tombstones in the trace (and in cfstats). That is, when the row is deleted, it generates a range tombstone while it generates cell tombstones with TTL, which is why it shows up in tracing/cfstats in the latter case but not in the former. It's something we certainly should fix (though at least in tracing we might want to log RT separately) but it doesn't have other consequences than being confusing when you look at traces/cfstats.
        Hide
        anubhavk Anubhav Kale added a comment -

        Thanks for the update.

        Based on the code in SliceQueryFilter (2.1.9 Tag) where the TombstoneoverwhelmingException is thrown, it appears that range tombstones don't contribute to this counting. Is this the expected behavior (seems wrong to me) ? So, I am not sure if this is just a logging issue or has more implications.

        Show
        anubhavk Anubhav Kale added a comment - Thanks for the update. Based on the code in SliceQueryFilter (2.1.9 Tag) where the TombstoneoverwhelmingException is thrown, it appears that range tombstones don't contribute to this counting. Is this the expected behavior (seems wrong to me) ? So, I am not sure if this is just a logging issue or has more implications.
        Hide
        slebresne Sylvain Lebresne added a comment -

        The tombstone warning is covered by CASSANDRA-8527 (long story short, we do need to account for them but we're not sure we want to do so in stable releases since this could be surprising to some and hasn't proved so far to be a huge issue).

        Show
        slebresne Sylvain Lebresne added a comment - The tombstone warning is covered by CASSANDRA-8527 (long story short, we do need to account for them but we're not sure we want to do so in stable releases since this could be surprising to some and hasn't proved so far to be a huge issue).

          People

          • Assignee:
            Unassigned
            Reporter:
            anubhavk Anubhav Kale
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development