Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats!! Jon Haddad 于2025年5月17日周六 08:10写道： > Congrats!! > > > On Fri, May 16, 2025 at 4:13 PM Alexandre DUTRA wrote: > >> Great news, and so well deserved! Congratulations Bret! >> >> Le ven. 16 mai 2025 à 19:00, Jeremiah Jordan a >> écrit : >> >>> Congrats Bret! >>> >>> On May 16, 2025 at 4

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats!! On Fri, May 16, 2025 at 4:13 PM Alexandre DUTRA wrote: > Great news, and so well deserved! Congratulations Bret! > > Le ven. 16 mai 2025 à 19:00, Jeremiah Jordan a > écrit : > >> Congrats Bret! >> >> On May 16, 2025 at 4:00:12 PM, Mick Semb Wever wrote: >> >>> >>> The Project Manag

Re: Welcome Bret McGuire as Cassandra PMC Member!

Great news, and so well deserved! Congratulations Bret! Le ven. 16 mai 2025 à 19:00, Jeremiah Jordan a écrit : > Congrats Bret! > > On May 16, 2025 at 4:00:12 PM, Mick Semb Wever wrote: > >> >> The Project Management Committee (PMC) for Apache Cassandra is delighted >> to announce that Bret McG

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats Bret! On May 16, 2025 at 4:00:12 PM, Mick Semb Wever wrote: > > The Project Management Committee (PMC) for Apache Cassandra is delighted > to announce that Bret McGuire has joined the PMC! Thank you Bret for all > your contributions to the project over the years, especially with so ma

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats Bret!

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats Bret! Well deserved On 2025/05/16 21:00:12 Mick Semb Wever wrote: > The Project Management Committee (PMC) for Apache Cassandra is delighted to > announce that Bret McGuire has joined the PMC! Thank you Bret for all your > contributions to the project over the years, especially with so

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congratulations Bret! > On May 16, 2025, at 4:29 PM, Aaron Ploetz wrote: > > Congratulations Bret! > >> On May 16, 2025, at 4:13 PM, Ekaterina Dimitrova >> wrote: >> >>  >> Congrats, Bret!!! Welcome and thank you for all you do! >> >> On Fri, 16 May 2025 at 17:09, Marouan REJEB >

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congratulations Bret!On May 16, 2025, at 4:13 PM, Ekaterina Dimitrova wrote:Congrats, Bret!!! Welcome and thank you for all you do!On Fri, 16 May 2025 at 17:09, Marouan REJEB wrote:Congrats!On Fri, May 16, 2025 at 11:02 PM Mick Semb Wever wrote:The Proj

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

I agree we need to do a better job and wording this so people can understand what is happening. For your exact example here, you are actually looking at too broad of a thing. The exact requirements are not at the full cluster level, but actually at the “token range” level at which repair operate

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats Bret! On Fri, May 16, 2025, at 5:13 PM, Ekaterina Dimitrova wrote: > Congrats, Bret!!! Welcome and thank you for all you do! > > On Fri, 16 May 2025 at 17:09, Marouan REJEB wrote: >> Congrats! >> >> On Fri, May 16, 2025 at 11:02 PM Mick Semb Wever wrote: >>> >>> The Project Managemen

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats! Kind Regards, Brandon On Fri, May 16, 2025 at 4:00 PM Mick Semb Wever wrote: > > > The Project Management Committee (PMC) for Apache Cassandra is delighted to > announce that Bret McGuire has joined the PMC! Thank you Bret for all your > contributions to the project over the years,

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats, Bret!!! Welcome and thank you for all you do! On Fri, 16 May 2025 at 17:09, Marouan REJEB wrote: > Congrats! > > On Fri, May 16, 2025 at 11:02 PM Mick Semb Wever wrote: > >> >> The Project Management Committee (PMC) for Apache Cassandra is delighted >> to announce that Bret McGuire ha

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats Bret! 🎉 On Fri, May 16, 2025 at 4:09 PM Marouan REJEB wrote: > Congrats! > > On Fri, May 16, 2025 at 11:02 PM Mick Semb Wever wrote: > >> >> The Project Management Committee (PMC) for Apache Cassandra is delighted >> to announce that Bret McGuire has joined the PMC! Thank you Bret for

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats! On Fri, May 16, 2025 at 11:02 PM Mick Semb Wever wrote: > > The Project Management Committee (PMC) for Apache Cassandra is delighted > to announce that Bret McGuire has joined the PMC! Thank you Bret for all > your contributions to the project over the years, especially with so many >

Welcome Bret McGuire as Cassandra PMC Member!

The Project Management Committee (PMC) for Apache Cassandra is delighted to announce that Bret McGuire has joined the PMC! Thank you Bret for all your contributions to the project over the years, especially with so many of the drivers. The PMC - Project Management Committee - manages and guides t

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Unfortunately, no. When building Merkle trees for small token ranges in the base table, those ranges may span the entire MV token range. As a result, we need to scan the entire MV to generate all the necessary Merkle trees. For efficiency, we perform this as a single pass over the entire table rath

Re: One Board to Rule Them All (or: ecosystem JIRA's are now integrated in our kanban board)

Thank you for doing this Josh! On Fri, May 16, 2025 at 11:51 AM Josh McKenzie wrote: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484 > > I've done the following: > >1. added all the cassandra subprojects into the base query that feeds >the board >2. added swimla

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I spoke too soon - endless questions are not over :) Since the data that's going to be repaired only covers a range, I wonder if it makes sense to have the ability to issue a minimalist snapshot that only hardlinks SSTables that are in a token range. Based on what you (Runtian) have said above, o

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

The wording is subtle and can be confusing... It's important to distinguish between: 1. "You need to start and complete a repair within any gc_grace_seconds window" 2. "You need to start and complete a repair within gc_grace_seconds" #1 is a sliding time window for any time interval in which the

One Board to Rule Them All (or: ecosystem JIRA's are now integrated in our kanban board)

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484 I've done the following: 1. added all the cassandra subprojects into the base query that feeds the board 2. added swimlanes for the various ecosystem projects (including a 1.0 release lane for analytics and sidecar) 3. added q

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

> You need to *start and complete* a repair within any gc_grace_seconds window. Exactly this. And since "any gc_grace_seconds" does not mean "any gc_grace_window from which a repair starts"... the requirement needs to be that the duration to "start and complete" two consecutive full repairs is with

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

. > e.g., assume gc_grace_seconds=10 days, a repair takes 5 days to run > * Day 0: Repair 1 starts and processes token A > * Day 1: Token A is deleted resulting in Tombstone A that will expire on > Day 11 > * Day 5: Repair 1 completes > * Day 7: Repair 2 starts > * Day 11: Tombstone A expires

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

Thanks Jeff for the quick response. But I believe successfully starting and completing a repair every 7 day is still not enough to guarantee that a tombstone would not expire: e.g., assume gc_grace_seconds=10 days, a repair takes 5 days to run * Day 0: Repair 1 starts and processes token A * Day 1

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

> On May 16, 2025, at 10:22 AM, Mike Sun wrote: > > The Cassandra docs > > advise: >> >> At a minimum, repair should be run often enough that the gc grace period >> never expires on unrepaired data. Otherwise, d

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Thats the critical bit i was missing, thank you Blake. I guess we’d need to have unlimited height trees then, since you’d need to be able to update the hashes of individual partitions, and we’d also need to propagate the hashes up every time as well. I’m curious what the cost will look like with t

Stricter repair time requirements necessary to prevent data resurrection than advised by docs

The Cassandra docs advise: > > At a minimum, repair should be run often enough that the gc grace period > never expires on unrepaired data. Otherwise, deleted data could reappear. > With a default gc grace period of 10

Re: [VOTE] Release Apache Cassandra 4.1.9

+1 On Fri, May 16, 2025 at 8:53 AM Chris Lohfink wrote: > +1 > > On Fri, May 16, 2025 at 7:33 AM Brandon Williams wrote: > >> Proposing the test build of Cassandra 4.1.9 for release. >> >> sha1: 82fc35b0136cc5f706032759d73ac5ae02c20871 >> Git: https://github.com/apache/cassandra/tree/4.1.9-tent

Re: [VOTE] Release Apache Cassandra 4.1.9

+1 On Fri, May 16, 2025 at 7:33 AM Brandon Williams wrote: > Proposing the test build of Cassandra 4.1.9 for release. > > sha1: 82fc35b0136cc5f706032759d73ac5ae02c20871 > Git: https://github.com/apache/cassandra/tree/4.1.9-tentative > Maven Artifacts: > > https://repository.apache.org/content/re

[VOTE] Release Apache Cassandra 4.1.9

Proposing the test build of Cassandra 4.1.9 for release. sha1: 82fc35b0136cc5f706032759d73ac5ae02c20871 Git: https://github.com/apache/cassandra/tree/4.1.9-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1393/org/apache/cassandra/cassandra-all/4.1.9