# Can we use tombstone\_gc = {'mode': 'repair'} for GSI tables?
**URL:** https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273
**Category:** ScyllaDB
**Tags:** repair, tombstone, secondary-index
**Created:** [February 5, 2024, 1:31am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273 "2024-02-05T01:31:54Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@vincent](https://forum.scylladb.com/u/vincent)
#### Post date: [February 5, 2024, 1:31am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/1 "2024-02-05T01:31:54Z")
I have two questions here about tombstone\_gc = {‘mode’: ‘repair’} for GSI tables.
1. I am not sure whether tombstone\_gc = {‘mode’: ‘repair’} is supported for GSI tables or not.
2. How can I ensure that the tombstone\_gc mode has been changed for GSI tables? I’ve noticed that [system\_schema.tables displays data of extensions column in a wrong unclear byte format #10309](https://github.com/scylladb/scylladb/issues/10309) provides a method to check the tombstone\_gc mode for base table. But it might not be useful for GSI tables.
---
### Author:  [@Botond\_Denes](https://forum.scylladb.com/u/Botond_Denes)
#### Post date: [February 14, 2024, 9:32am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/2 "2024-02-14T09:32:21Z")
AFAIK, `tombstone_gc = {'mode': 'repair'}` should work with any table, that can be repaired and the materialized view that is backing the GSI certainly can be repaired.
@nyh are you aware of any potential gotchas around this?
---
### Author:  [@nyh](https://forum.scylladb.com/u/nyh)
#### Post date: [February 14, 2024, 9:52am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/3 "2024-02-14T09:52:27Z")
Yes, a materialized view is a normal table under the hood, but one cannot modify it by ALTER TABLE and you need to do ALTER MATERIALIZED VIEW. I believe, but **did not test myself** that you can modify this tombstone\_gc with ALTER MATERIALIZED VIEW. I also believe (but didn’t test) that if you already have a base table with tombstone\_gc and later create a view, this view will inherit this setting. But both beliefs should be tested (I’ll do this later).
Beyond that, there is a separate question of whether users **should** repair view tables. My view (sorry for the pun) is that they should - they should repair base tables and then view tables. There are known rare inconsistencies (“ghost rows”) that may arise from repairing view tables, but I think the benefits of such repair - including tombstone GC - greatly outweigh the risks. But this is still an open discussion.
CC @Konstantin_Osipov @Yaniv_Kaul
---
### Author:  [@Yaniv\_Kaul](https://forum.scylladb.com/u/Yaniv_Kaul)
#### Post date: [February 14, 2024, 10:17am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/4 "2024-02-14T10:17:41Z")
We’ve recently added (via [[Backport 5.2] schema: add scylla specific options to schema description by Jadw1 · Pull Request #16786 · scylladb/scylladb · GitHub](https://github.com/scylladb/scylladb/pull/16786) ) a reasonable way to see tombstone\_gc for tables.
---
### Author:  [@nyh](https://forum.scylladb.com/u/nyh)
#### Post date: [February 14, 2024, 3:12pm UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/5 "2024-02-14T15:12:57Z")
I wrote a test and confirmed (on latest ScyllaDB master) that:
1. The tombstone\_gc option can be set on a materialized view either when it’s first created with CREATE MATERIALIZED VIEW or when later with ALTER MATERIALIZED VIEW
2. The current setting is correctly printed with the “DESC ” statement. This is the new server-side describe statement, that replaced the older statement that used to live in CQL (and didn’t support tombstone\_gc or other non-standard options).
3. The gc\_mode set on a base table is **not** inherited by its views - you need to set it separately for each view (again, while creating the view or later). I don’t know if this is a bug or a feature, but it shouldn’t cause any problems once you know you need to set it per view separately.
---
### Author:  [@vincent](https://forum.scylladb.com/u/vincent)
#### Post date: [February 20, 2024, 8:49am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/6 "2024-02-20T08:49:33Z")
> [@nyh](#):
>
> There are known rare inconsistencies (“ghost rows”) that may arise from repairing view tables
Thanks very much for your reply. However, I am still confused about the rare inconsistencies (“ghost rows”) which may arise from repairing view tables. Can you give me some specific examples or issues about this?
---
### Author:  [@vincent](https://forum.scylladb.com/u/vincent)
#### Post date: [February 22, 2024, 9:52am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/7 "2024-02-22T09:52:05Z")
Can you give me some specific examples or issues about “ghost rows” which arise from repairing view tables? Thanks! @nyh
---
### Author:  [@bo\_li](https://forum.scylladb.com/u/bo_li)
#### Post date: [May 20, 2024, 7:32am UTC](https://forum.scylladb.com/t/can-we-use-tombstone-gc-mode-repair-for-gsi-tables/1273/8 "2024-05-20T07:32:21Z")
When I enabled the `gc_mode=repair` function of the base table and view table, there was a phenomenon of missing certain attributes in the records of my view table. During this period, the cluster is scheduling repairs normally. Under what circumstances does this phenomenon occur and is it related to function `gc_mode=repair` ? Thanks!