> That's not how gc_grace_seconds work.
> gc_grace_seconds controls how much time *after* a tombstone can be deleted, 
> it can actually be deleted, in order to give you enough time to run repairs.
> Say you have data that is about to expire on March 16 8am, and 
> gc_grace_seconds is 10 days.
> After Mar 16 8am that data will be a tombstone, and only after March 26 8am, 
> a compaction  *might* remove it, if all other conditions are met.

You are right. I do not understand why it is implemented this way, but you are 
100 % correct that it works this way.

I thought that gc_grace_seconds is all about being able to repair the table 
before tombstones are removed, so that deleted data cannot repappear. But when 
the data has a TTL, it should not matter whether the original data ore the 
tombstone is synchronized as part of the repair process. After all, the 
original data should turn into a tombstone, so if it was present on all nodes, 
there is no risk of deleted data reappearing. Therefore, I think it would make 
more sense to start gc_grace_seconds when the data is inserted / updated. I 
don’t know why it was not implemented this way.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to