Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

Hi Scott, – What's this for? I'd appreciate a detailed explanation of what "Enhance > CQLSSTableWriter to notify clients on sstable production" does and how it's > meant to be used. Why is it needed for rolling upgrades? The phrasing of > the ticket right now reads as nice-to-have rather than must

Re: [VOTE] Release Apache Cassandra 4.1.6

Sorry to veer off from a vote in a vote thread. @Alex, can you say more about this statement: > " I think I would prefer to not introduce the change I have proposed (the one that would bring back non-binary compatibility)." If we have a path that resolves the issue and also maintains full compati

Re: Urgent: Potential Privacy Leakage Detected in Your Docker Hub Images

Hequan, thanks for your email. If you'd like to report a potential security/privacy issue in Apache Cassandra, a few paths are available: – Email priv...@cassandra.apache.org to report the issue privately to the Apache Cassandra Project Management Committee, who can privately review your report

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

There are a few things unclear to me in this thread and the ticket, and details in the Jira are slim. Yifan / others supportive of backporting this feature, could you help me answer these questions? – What's this for? I'd appreciate a detailed explanation of what "Enhance CQLSSTableWriter to not

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

I'm kind of neutral on this, maybe -0. It's a small enough patch, but it's of limited value, given that Cassandra Analytics doesn't work with vnodes. That's the overwhelming majority of deployments. So I'm not really sure what we gain here. On Wed, Jul 31, 2024 at 1:58 PM Yifan Cai wrote: > Hi

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

On Tue, Jul 30, 2024 at 11:47 AM Mick Semb Wever wrote: > This also incentivises intentionally not introducing support for that api > in older mainlines. We KISS, if the user wants that ecosystem benefit they > need to upgrade to at least mainline X. > > Once older mainlines have it then we have

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

Hi PMC team, There are so far two +1 and one -1. Please vote if you want to. It is open for another 12 hours. 4.1 is to be released. I would like to include the patch, if possible, according to the vote result. I recognize that patches to stable releases can be risky. When talking about the trad

Re: [VOTE] Release Apache Cassandra 4.1.6

+1 to proceeding with a simple upgrade note in NEWS On Wed, Jul 31, 2024 at 12:50 PM Josh McKenzie wrote: > Unfortunately, I can not immediately see a good way to provide the > critical bugfix of CASSANDRA-19534 > , affecting all > Cassandra

Re: [DISCUSS] Removing support for deterministic table IDs

5.0 and trunk patches are up in CASSANDRA-19809 if anyone is interested in reviewing. On Wed, Jul 31, 2024 at 1:55 PM Jeff Jirsa wrote: > Would also vote to remove when TCM is available/stable. > > More words on the create, drop, re-create,

Re: [DISCUSS] Removing support for deterministic table IDs

Would also vote to remove when TCM is available/stable. More words on the create, drop, re-create, in case it’s not familiar to people: - Create assigns an ID - Drop removes definition and data - Create assigns an ID If non-deterministic, we had races where an ID was assigned concurrently in tw

Re: [DISCUSS] Removing support for deterministic table IDs

> what’s the motivation for removal? One thing that also makes it better to remove is that this adds the ABA problem into our tables, where as removing it fixes that… If you create a table “foo”, drop it, then recreate “foo”, the 2 “foo” tables share the same tableId, which can trick things to

Re: [VOTE] Release Apache Cassandra 4.1.6

> Unfortunately, I can not immediately see a good way to provide the critical > bugfix of CASSANDRA-19534 > , affecting all > Cassandra users, without making at least some change in this API. > > I personally think that this method is very

Re: [DISCUSS] The way we log

I reckon we could start using slf4j/logback Markers to tag individual logging statements as foreground/background (or, ideally, with more granularity than that - separate out repair, compaction, schema, reads/wrties, etc.). > On 24 Jul 2024, at 16:02, Josh McKenzie wrote: > > I argued this poi