I'd be happy to see this, but I agree with Scott and others that the
implications around the auto_repair table-level property and the
system_distributed tables that are added as part of CEP-37 should be
thoroughly understood and vetted.

I also wanted to note a few things about a possible backport:

* There is a branch that Jaydeep had been keeping in sync off of 4.1.6 (
https://github.com/apache/cassandra/pull/3367).  I'm not sure how up to
date it is but the last commit on the branch is Sep 21 2025.
* As for "How far to backport", from previous discussions I know there has
been an appetite to backport this to 4.1, but I'd be curious what the
appetite would be for 4.0.  I think if we backport it at all, we should be
aiming at least for 4.1 as a minimum.
* While the code in CEP-37 is rather isolated, maintaining it on 4.1+
should hopefully not add too much burden to maintain; however, we are
benefitting from changes in 5.0 (CASSANDRA-20092) for simplifying getting
amount of bytes a token range covers in an SSTable, where the 4.1
implementation makes some changes to BigTableScanner to get what we need (
https://github.com/apache/cassandra/pull/3367/files#diff-e8c75699e007d2ac1f3563865ee5b3769bae24eee75936e27c1d5c603aabd4cc),
which are less optimal than the impl used on trunk (but maybe not enough to
matter?).
* Some API changes around TCM meant how we look up replicas in AutoRepair
are different in 4.1/5.0 vs trunk.

Andy

On Tue, Dec 2, 2025 at 2:35 PM Brandon Williams <[email protected]> wrote:

> It still changes the schema hash in 4.0, yeah.
>
> Kind Regards,
> Brandon
>
> On Tue, Dec 2, 2025 at 2:34 PM Jeff Jirsa <[email protected]> wrote:
> >
> > Is it still the case (4.0, 4.1) where adding the table param changes the
> schema hash (including in the mixed mode during the first deploy), or is
> that a solved problem in 4.0+?
> >
> >
> >
> >
> > > On Dec 2, 2025, at 2:54 PM, Brandon Williams <[email protected]> wrote:
> > >
> > > Maybe I was too hasty with my vote, then.  I know from experience that
> > > once table params or new system table properties are added, rolling
> > > back is generally not possible.  That can perhaps be fixed in some way
> > > but nothing currently exists.
> > >
> > > Kind Regards,
> > > Brandon
> > >
> > > On Tue, Dec 2, 2025 at 1:49 PM C. Scott Andreas <[email protected]>
> wrote:
> > >>
> > >> The patch will need vetting for compatibility implications of
> upgrades from (e.g.,) 4.0 + CEP-37 to newer-versioned releases like Apache
> Cassandra 5.0.6 that don't have this change.
> > >>
> > >> Some sources of potential incompatibility (briefly scanned, not
> vetted) look like:
> > >>
> > >> – Table params:
> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20#diff-44546e8ca2f2a8a986ec2b16f837b7526f2444e5fb2c6367abf35d8756fd0e51R578-R631
> > >> – system_distributed generation bump:
> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20#diff-68edc51628c3cf6a0e9dbcff0dd697e130b952e0f328699db5541a21300aa0b2R89-R104
> > >> – System table:
> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20#diff-68edc51628c3cf6a0e9dbcff0dd697e130b952e0f328699db5541a21300aa0b2R166
> > >>
> > >>
> > >> On Dec 2, 2025, at 11:36 AM, Josh McKenzie <[email protected]>
> wrote:
> > >>
> > >>
> > >> In a couple prior discuss threads, the topic of backporting
> in-project repair scheduling (CEP-37) came up a few times and the consensus
> seemed to be that everyone was receptive to us backporting this feature to
> all GA branches. The goal of this thread is to focus on that and formalize
> discussion and consensus before a potential vote.
> > >>
> > >> Here's a link to the CEP-37:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37%3A+Apache+Cassandra+Unified+Repair+Solution
> > >>
> > >> And a link to the JIRA for the impl:
> https://issues.apache.org/jira/browse/CASSANDRA-19918
> > >>
> > >> And here's the PR:
> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20
> > >>
> > >> So: what do we think?
> > >>
> > >> I'm personally +1 on allowing this to be backported to 4.0, 4.1, and
> 5.0.
> > >>
> > >> -----
> > >> Prior reading:
> > >> - Discussing potential of a backport branch:
> https://lists.apache.org/thread/xbxt21rttsqvhmh8ds9vs2cr7fx27w3k
> > >> - Discussing understanding fork motivations:
> https://lists.apache.org/thread/5nv1f4bng4nw5ofgh135k5pf2f6l6lgl
> > >>
> > >>
> >
>

Reply via email to