> On Apr 11, 2025, at 1:15 PM, Jon Haddad wrote:
>
>
> I also keep running up against my concern about treating object store as a
> write back cache instead of write through. "Tiering" data off has real
> consequences for the user, the big one being data loss, especially with
> regards to
Not Patrick, but:
- would also love being closer to SQL
- there’s no work on this specific grammar, yet
- it would depend on a real query optimizer, which IS somewhat in flight (or at
least a cost based optimizer was proposed)
> On Apr 7, 2025, at 2:05 PM, Artem Golovko wrote:
>
> Hi Patrick,
Having played with the branch and confirmed it’s relatively isolated, I would love to see it mergedOn Mar 6, 2025, at 8:44 PM, Benedict Elliott Smith wrote:Because we want to validate against the latest code in trunk, else we are validating stale behaviours. The cost of rebasing is high, so we do
I think widely accepted that otel in general has won this stage of observability, as most metrics systems allow it and most saas providers support it. So Jon’s point there is important. The promise of unifying logs/traces/metrics usually (aka wide events) is far more important in the tracing side o
driver"? It is eventually using same thing, no?On Tue, Mar 4, 2025 at 12:47 PM Jeff Jirsa <jji...@gmail.com> wrote:Mounting an s3 bucket as a directory is an easy but poor implementation of object backed storage for databases Object storage is durable (most data loss is due to bugs not co
;? It is eventually using same thing, no?On Tue, Mar 4, 2025 at 12:47 PM Jeff Jirsa <jji...@gmail.com> wrote:Mounting an s3 bucket as a directory is an easy but poor implementation of object backed storage for databases Object storage is durable (most data loss is due to bugs not concurrent hardwa
Mounting an s3 bucket as a directory is an easy but poor implementation of object backed storage for databases Object storage is durable (most data loss is due to bugs not concurrent hardware failures), cheap (can 5-10x cheaper) and ubiquitous. A huge number of modern systems are object-storage-on
The schema has to be durable on disk for cold start
You could put a virtual facade in front of it for drivers but you need a
durable physical copy of that schema somewhere, right?
> On Feb 20, 2025, at 3:57 PM, Bernardo Botella
> wrote:
>
> Hi everyone!
>
> As part of Jira ticket (CASSANDR
f the improvements are that minor.JordanOn Tue, Jan 21, 2025 at 1:57 PM Jeff Jirsa <jji...@gmail.com> wrote:We expect users to treat patch and minor releases as low risk. Changing something deep in the storage engine to be 1% faster is not worth the risk, because most users will skip
We expect users to treat patch and minor releases as low risk. Changing
something deep in the storage engine to be 1% faster is not worth the risk,
because most users will skip the type of qualification that finds those one in
a billion regressions.
Patch releases are for bug fixes not perf imp
t;>>>>>> can't use it for 6 months because you're using
>>>> analytics lib
>>>>>>>>> and
>>>>>>>>>>>> the people
>>>>>>>>>>>>>>>> that contribute to
I’m going to type a lot of extra words mostly for people just barely familiar
with this part of the codebase, because it may or may not be useful to passive
observers (it wasn’t to me, so I’m mostly echo’ing the things I just went and
learned this morning):
The HLL cardinality is used for bas
You’ve added a ton of API surface to transaction behavior and cluster
management. The TCM may or may not be strictly breaking, but they’re
fundamentally very very different, so even with semver as the only standard, I
think you can justify a major.
But also, let’s just acknowledge that marketin
> On Dec 9, 2024, at 10:52 AM, Jeremy Hanna wrote:
>
>
>
> In the case of UCS, is it in a beta state until we resolve the discussions
> around UX/documentation? From a functional and production usage perspective,
> it has been the only compaction strategy available for users in DataStax'
On 2024/12/09 17:33:09 Benedict wrote:
> I think it would make sense to support overriding the default FP in the UCS
> parameters, so we can treat it as a direct replacement. Desiree FP is
> directly related to sstable overlaps after all.
>
> Can you think of any other usability gaps like t
On 2024/12/09 16:26:45 Benedict wrote:
> I think it’s important to remember that UCS broadly speaking subsumes both LCS
> and STCS, with various subtle but important refinements. So while it offers a
> broader parameter space it might be best to conceive of it as a suite of
> compaction strategi
> On Dec 7, 2024, at 7:08 PM, Mick Semb Wever wrote:
>
> Chiming in with my two cents…
>
>
>> When people have the luxury of working in environments where clusters are
>> massively over provisioned, LCS as a default makes a lot of sense, because
>> there's not much downside. The use cases
People who know enough to read the docs to find those profiles know how to read
the docs to choose the right compaction already. Beyond that, it just clutters
up the grammar and metadata.
The reality here is there’s no single compaction strategy that works for
everyone, so unless there’s strong
And it works for that most of the time, so what’s the concern? “You lose
throughput because iops / write amplification go up, so the perf of the default
install goes down” ? (But the cost per byte goes way down, too)?
> On Dec 6, 2024, at 8:01 PM, Brad wrote:
>
> > Could you elaborate what
I’m probably closely aligned with Chris here, fwiw.
- Jeff
> On Dec 6, 2024, at 7:40 PM, Chris Lohfink wrote:
>
> While I am actually +1 on LCS being default as it handles more use cases well
> compared to STCS. I am -1 on UCS being default anywhere currently, the UX is
> horrible, documenta
It feels uncomfortable asking users to rely on a third party that’s as
heavy-weight as spark to use a built-in feature.
Can we really not do this internally? I get that the obvious way with merkle
trees is hard because the range fanout of the MV using a different partitioner,
but have we tried
> On Nov 5, 2024, at 4:12 AM, Bowen Song via user
> wrote:
>
> Writes on this node starts to timeout and fail. But if left untouched, it's
> only gonna get worse, and eventually lead to JVM OOM and crash.
>
> By inspecting the heap dump created at OOM, we can see that both of the
> Memtable
> On Oct 28, 2024, at 9:52 PM, Alexander Dejanovski
> wrote:
>
>
>
>> If a repair session finishes gracefully, then this timeout is not
>> applicable. Anyway, I do not have any strong opinion on the value. I am open
>> to lowering it to 1h or something.
> True, it will only delay killing
> On Oct 1, 2024, at 7:26 PM, Josh McKenzie wrote:
>
>> However it is used by a number of other features as a dependency such as
>> analytics, backup/restore, repair, metrics, and CDC
> It seems like a natural pressure relief valve for moving operations out of a
> core C* node that are well s
> On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe wrote:
>
> Hello fellow secondary index enjoyers!
>
> If you're familiar with index queries, you probably know that they are
> treated as range reads no matter what. This is true even if the user query
> restricts results to a single partition.
Transactional metadata and Accord should make it MUCH easier to do duplication avoiding CDC (and I was going to note that someone should ensure that the interfaces exposed to the public are stable enough not to change the published api once those exist)On Sep 29, 2024, at 7:04 PM, Patrick McFadin
tion possible, i.e. avoids data loss with manual intervention. (Logging and metrics also face the same problem with false positives.)I'm +0 for rejection default in 5.0.1, and +1 for only logging default in 4.xOn Thu, 12 Sept 2024 at 18:56, Jeff Jirsa <jji...@gmail.com> wrote:This patch is so ha
On Sep 12, 2024, at 12:22 PM, J. D. Jordan wrote:I have lost sleep (and data) over this multiple times in the past few months, that was only recently tracked down to this exact scenario.+1 for including it in all active releases and enabling the failure of the writes on “wrong” nodes by default.I
This patch is so hard for me.
The safety it adds is critical and should have been added a decade ago.
Also it’s a huge patch, and touches “everything”.
It definitely belongs in 5.0. I’d probably reject by default in 5.0.1.
4.0 / 4.1 - if we treat this like a fix for latent opportunity for da
Rei used to be semi-active on the Cassandra lists. He took over lz4-java a few
years ago. Wonder if he’d be willing to pass the torch if he no longer has
time? CC’ing him in case he’s following email.
> On Aug 6, 2024, at 8:47 AM, Jordan West wrote:
>
> Oof this is a tough one. I agree wi
As Josh mentioned previously, not all procedural votes treat -1s as vetoes. I remain against the backport to 4.0 and 4.1, but not a veto. -1 for those branches. On Aug 3, 2024, at 11:19 PM, Yifan Cai wrote:Hi,I am proposing backporting CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0. There is a dis
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
It’s a 10 year old flaw in an 18 month old branch. Why does it need to go into
4.1, it’s not a regression and it clearly breaks compatibility?
> On Jul 30, 2024, at 8:52 AM, Jon Haddad wrote:
>
> This patch fixes a long standing issue that's the root cause of availability
> failures. Eve
for a vote. SureI’m -1 on 4.0 and 4.1- JeffOn Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa <jji...@gmail.com> wrote:Everyone has a low risk change they want to backport to every branch, 4.0 and 4.1 in particular are way past the point we should be adding features
The policy exists and it’s
Everyone has a low risk change they want to backport to every branch, 4.0 and
4.1 in particular are way past the point we should be adding features
The policy exists and it’s a pure feature not a regression
> On Jul 26, 2024, at 9:59 AM, Brandon Williams wrote:
>
> Given how low risk thi
+1 Should block
> On Jul 26, 2024, at 8:25 AM, Štefan Miklošovič wrote:
>
>
> I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I
> think it was introduced in (2) and it behaves like this (3).
>
> Regards
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-19779
>
(Answering this as a cassandra person, don’t confuse this reply as
board/foundation guidance)
The legal landscape is rapidly evolving with the CRA. The answer may change in
the future, but I think “we have a dependency we ship that’s user-accessible
and known to be abandoned” is an unhappy stat
+1
> On Jun 25, 2024, at 5:04 AM, Mick Semb Wever wrote:
>
>
>
> Proposing the test build of Cassandra 5.0-rc1 for release.
>
> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.o
+1
Thank you for being explicit about which authors of gocql have signed the ICLA
> Where The Gocql Authors for copyright purposes are below. Those marked with
> asterisk have agreed to donate (copyright assign) their contributions to the
> Apache Software Foundation, signing CLAs when appropriat
If we have a public-facing API that we’re contemplating releasing to the
public, and we don’t think it’s needed, we should remove it before it’s
launched and we’re stuck with it forever.
> On Jun 20, 2024, at 9:55 AM, Jeremiah Jordan wrote:
>
> +1 from me for 1, just remove it now.
> I thi
fourth seems incredibly unlikely. The third seems maybe possible, but why not spec out the full range with the CEP instead of assuming iterative implementation?On Jun 2, 2024, at 20:59, Jeff Jirsa wrote:Would this be implemented solely in the write path? Or would you also try to enforce it in the
Would this be implemented solely in the write path? Or would you also try to enforce it in the read and sstable/compaction/repair paths as well? On May 31, 2024, at 23:24, Bernardo Botella wrote:Hello everyone,I am proposing this CEP:CEP-42: Constraints Framework - CASSANDRA - Apache Software Fo
You can remove the shadowed values at compaction time, but you can’t ever fully
propagate the range update to point updates, so you’d be propagating all of the
range-update structures throughout everything forever. It’s JUST like a range
tombstone - you don’t know what it’s shadowing (and can’t,
Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going forward?
I think Jordan and German had an interesting insight, or at least their comment made me think about this slightly differently, and I’m going to repeat it so it’s not lost in the discussion about zerocopy / sendfile.The CEP treats this as “move a live instance from one machine to another”. I know wh
On 2024/02/21 09:26:53 Jarek Potiuk wrote:
> Hello dear Cassandra community,
>
> I am a fellow PMC member of Apache Airflow and recently we started to look
> at the Cassandra provider of ours in the context of Python 3.12 migration
> and the integration raised my interest.
>
> TL;DR; I am quit
1) If there’s an “old compatible default” and “latest recommended settings”,
when does the value in “old compatible default” get updated? Never?
2) If there are test failures with the new values, it seems REALLY IMPORTANT to
make sure those test failures are discovered + fixed IN THE FUTURE TOO.
Auth is one of those things that needs to be a bit more concrete In the scenario you describe, you already have an option to deploy the auth in piece partially during the rollout (pause halfway through) in the cluster and look for asymmetric connections, and the option to drop in a new Authenticato
The problem with generalizing things is if you’re behind on compaction, reads get expensive, so you pause compaction completely, you’re SOL and you’ll eventually have to throttle traffic to recoverThe SEDA model is bad at back pressure and deferred cost makes it non-obvious which resource to slow t
> On Dec 14, 2023, at 1:51 PM, Dinesh Joshi wrote:
>
>
>>
>> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote:
>>
>> 1. Fork OHC and start publishing under a new package name and continue to
>> use it
>
> Who would fork it? Where would you fork it? My first instinct is that this
> wo
I'm also torn on the CEP as presented. I think some of it is my negative
emotional response to the examples - e.g. I've literally never seen a real
use case where unfolding constants matters, and I'm trying to convince
myself to read past that.
I also cant tell what exactly you mean when you say "
-0 to cutting a beta we know has a very obvious correctness flaw with a fix
already understood
On Tue, Nov 28, 2023 at 10:40 AM Patrick McFadin wrote:
> JD, that wasn't my point. It feels like we are treating a beta like an RC,
> which it isn't. Ship Beta 1 now and Beta 2 later. We need people
,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understandin
On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever wrote:
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
I think this presumes that 5.0 GA is date driven instead
+1
On Mon, Oct 2, 2023 at 9:53 PM Mick Semb Wever wrote:
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF. This does not require acknowledgement
> before the vote.
>
Claude if you’re still at POC phase does it make sense for you to perhaps help validate / qualify the work that Henrik seems willing to rebase rather than reinventing the wheel? On Sep 26, 2023, at 11:23 PM, Claude Warren, Jr via dev wrote:I spent a little (very little) time building an S3 implem
- I think this is a great step forward.
- Being able to move sstables around between tiers of storage is a feature
Cassandra desperately needs, especially if one of those tiers is some sort
of object storage
- This looks like it's a foundational piece that enables that. Perhaps by a
team that's alr
To do that, the cassandra PMC can open a legal JIRA and ask for a (durable,
concrete) opinion.
On Fri, Sep 22, 2023 at 5:59 AM Benedict wrote:
>
>1. my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims to
On Wed, Sep 13, 2023 at 9:25 AM Ekaterina Dimitrova
wrote:
> Jeff, isn’t this ok as long as it is used only in tests? If we are not
> sure we can open a Jira to legal?
>
> On Wed, 13 Sep 2023 at 12:23, Jeff Jirsa wrote:
>
>> Just to be clear - this repo?
>> ht
Just to be clear - this repo?
https://github.com/haifengl/smile/blob/master/LICENSE
That shows GPL + Commercial?
On Wed, Sep 13, 2023 at 9:10 AM Brandon Williams wrote:
> I don't see any problem with this, +1.
>
> Kind Regards,
> Brandon
>
>
> On Wed, Sep 13, 2023 at 11:09 AM Mike Adamson
>
Given the disclaimer, can you just confirm why we'd cut an alpha now -
we're trying to lock protocols and give other people an integration target,
presumably?
On Fri, Aug 25, 2023 at 8:14 AM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER,
+1
On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie wrote:
> 2) keep it there in 5.0 but mark it @Deprecated
>
> I'd say Deprecate, log warnings that it's not supported nor maintained and
> people to use it at their own risk, and that it's going to be removed.
>
> That is, assuming the maintenance
On Thu, Jun 22, 2023 at 11:23 PM Berenguer Blasi
wrote:
> Hi all,
>
> Given we're already introducing a new sstable format (OA) in 5.0 I would
> like to try to get this in before the freeze. The point being that
> sstables with lots of small partitions would benefit from a smaller DT
> at partiti
Either would be better than today.
On Thu, Jun 22, 2023 at 1:57 PM Jordan West wrote:
> Hi,
>
> I’m wondering if there is appetite to change the default SSL provider for
> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
> deployment as well as others I’m aware of make this
+1
On Tue, Jun 13, 2023 at 7:15 AM Jeremy Hanna
wrote:
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of
> the donation. Nothing more.
> The plan is to introd
On Mon, Jun 12, 2023 at 10:18 AM Mick Semb Wever wrote:
>
>
> On Mon, 12 Jun 2023 at 15:02, Maxim Muzafarov wrote:
>
>> Hello everyone,
>>
>> I would like to make the source code of the Cassandra project more
>> visible to people outside of the Cassandra Community and highlight the
>> typical kn
On Mon, Jun 12, 2023 at 9:50 AM Benjamin Lerer wrote:
> If you have rows that vary significantly in their size, your latencies
>> could end up being pretty unpredictable using a LIMIT BY . Being
>> able to specify a limit by bytes at the driver / API level would allow app
>> devs to get more dete
Changes like this always scare me, but the benefits probably outweigh the
risks. Probably obviously to whoever implements but please make sure if
this happens is super visible in both NEWS and simultaneously updates the
to-string / to-cql representation of the schema in cqlsh / drivers /
snapshots
On Thu, Apr 27, 2023 at 7:39 AM Jonathan Ellis wrote:
> It's been a while, so I may be missing something, but do we already have
> fixed-size lists? If not, I don't see why we'd try to make this fit into a
> List-shaped problem.
>
We do not. The proposal got closed as wont-fix
https://issues.ap
KEYSPACE at least makes sense in the context that it is the unit that
defines how those partitions keys are going to be treated/replicated
DATABASE may be ambiguous, but it's ambiguity shared across the industry.
Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
it'll be u
On Tue, Mar 28, 2023 at 7:30 AM Jeremiah D Jordan
wrote:
> - Resources isolation. Having the said service running within the same JVM
> may negatively impact Cassandra storage's performance. It could be more
> beneficial to have them in Sidecar, which offers strong resource isolation
> guarantees
the compaction. I didn't realize that
> LCS would try to reduce the scope of the compaction. I can't find in the
> branch where it handles that.
>
> Branimir, can you point to where it handles the scenario?
>
> Thanks,
>
> Jeremy
>
>>> On Mar 17, 2
> On Mar 17, 2023, at 1:46 PM, Jeremy Hanna wrote:
>
>
>
> One much more graceful element of UCS is that instead of what was previously
> done with compaction strategies where the server just shuts down when running
> out of space - forcing system administrators to be paranoid about headro
On Wed, Mar 8, 2023 at 5:25 AM Bowen Song via dev
wrote:
> At the moment, when a read error, such as unrecoverable bit error or data
> corruption, occurs in the SSTable data files, regardless of the
> disk_failure_policy configuration, manual (or to be precise, external)
> intervention is require
Anyone have stats on how many people use RF > 3 per dc? (I know what it looks like in my day job but I don’t want to pretend it’s representative of the larger community) I’m a fan of fixing this but I do wonder how common this is in the wild. On Mar 7, 2023, at 9:12 AM, Derek Chen-Becker wrote:I
A huge number of people use this legal and unsafe combination - like anyone
running RF=3 in AWS us-west-1 (or any other region with only 2 accessible
AZs), and no patch is going to suddenly make that safe, and banning it
hurts users a lot.
If we're really going to ship a less-bad version of this,
When people are serious about this requirement, they’ll build the downgrade equivalents of the upgrade tests and run them automatically, often, so people understand what the real gap is and when something new makes it break Until those tests exist, I think collectively we should all stop pretending
I'm not even convinced even 8110 addresses this - just writing sstables in
old versions won't help if we ever add things like new types or new types
of collections without other control abilities. Claude's other email in
another thread a few hours ago talks about some of these surprises -
"Specific
+1
On Mon, Feb 6, 2023 at 8:16 AM Sam Tunnicliffe wrote:
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>
> Discussion:
> https://lists.apache.org/thread/h25skwkbdztz9h
Usually requires an offer to donate from the current owner, an acceptance
of that offer (PMC vote), and then the work to ensure that contributions
are acceptable from a legal standpoint (e.g. like the incubator -
https://incubator.apache.org/guides/transitioning_asf.html - "For
contributions compos
But it's not merge-than-review, because they've already been reviewed,
before being merged to the feature branch, by committers (actually PMC
members)?
You want code that's been written by one PMC member and reviewed by 2 other
PMC members to be put up for review by some random 4th party? For
Concurrent shouldn’t matter (they’re non-overlapping in the repro). And I’d personally be a bit surprised if table count matters that much. It probably just requires high core count and enough data that the streams actually interact with the rate limiter On Dec 11, 2022, at 10:32 AM, Mick Semb Weve
On Thu, Nov 17, 2022 at 12:47 PM J. D. Jordan
wrote:
> -1 on providing a bunch of choices and forcing users to pick one. We
> should have a default and it should be “good enough” for most people. The
> people who want to dig in and try other gc settings can still do it, and we
> could provide the
I'll withdraw my comment about friendliness of g1 vs cms. I think it's too
late to sneak it in, but wouldn't object formally.
offheap_objects is way too late to change given we shipped the alpha in May
and there are known, long lived bugs that multiple users have reported and
wouldn't have been te
G1 you can argue for with the changes in the JDK, though it's MUCH less
friendly to small heaps (e.g. probably our default simple user).
Offheap memtables are different though. If someone wants to attest that
offheap_objects get the same level of rigorous testing as the existing
default, that'd b
I don't think logging which policy violation was triggered is that big of
an ask?
"Password changed for user X, complying with policies (reuse, complexity,
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR: P
I expect that a lot of use cases will update M and insert into N tables
based on one condition, so if that's a problem with the grammar today, I
think it'd probably be worth the time to sort that out?
On Wed, Sep 21, 2022 at 12:42 PM David Capwell wrote:
> Caleb is making great progress on thi
“ The proposed mechanism for dealing with both of these failure types is to
enable a manual operator override mode. This would allow operators to inject
metadata changes (potentially overriding the complete metadata state) directly
on any and all nodes in a cluster. At the most extreme end of th
This type of feature is very useful, but it may be easier to analyze this
proposal if it’s compared with other DDM implementations from other databases?
Would it be reasonable to add a table to the proposal comparing syntax and
output from eg Azure SQL vs Cassandra vs whatever ?
> On Aug 19,
Stop node 1 before you start node 2, essentially mocking a full network
partition.
On Tue, Aug 9, 2022 at 11:57 AM Cheng Wang via dev
wrote:
> Thank you, Aleksey,
> Yes, I have tried this approach, the problem is there is a timing window
> that node 1 runs the CREATE TABLE while node 2 is down
ddress is when there are two CREATE TABLE
> queries running on two coordinator nodes concurrently, it might end up with
> 2 schema versions and they would never get resolved automatically because
> table id is random TimeUUID.
>
>
>
> On Mon, Aug 8, 2022 at 3:54 PM Jeff
Which (of the many) schema disagreement issue(s)?
On Mon, Aug 8, 2022 at 3:29 PM Cheng Wang via dev
wrote:
> Thank you for the reply, Brandon! It is helpful!
>
> I was thinking of creating a cluster with 2 nodes and having two
> concurrent CREATE TABLE statements running. But the test will be
The hypothetical concern described is around potential data resurrection -
would you still use resumable bootstrap if you knew that data deleted
during those STW pauses was improperly resurrected?
On Wed, Aug 3, 2022 at 2:40 PM Bowen Song via dev
wrote:
> I have benefited from the resumable boot
And would you allow a transaction that had > 1 named select and no modification
statements, but commit if 1=1 ?
> On Jun 4, 2022, at 2:45 PM, Jeff Jirsa wrote:
>
>
>
>> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote:
>>
>> Hi dev@,
>
> Firs
> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote:
>
> Hi dev@,
First, I’m ridiculously excited to see this.
>
> I’ve been working on a draft syntax for Accord transactions and wanted to
> bring what I have to the dev list to solicit feedback and build consensus
> before moving forwar
An easier fix here is just to put a close action into the commit message:
Closes #nnn
e.g.
https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
/ https://github.com/apache/cassandra/pull/1046
On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie wrote:
> I think the fact
We've done concurrent releases without security before, and you follow much
closer than others. I feel most people, if they saw all of the
changes reverted and a release of a single fix, would either instantly know
it's security (high confidence pointer to exactly which patch) OR assume
someone bot
We don't HAVE TO remove the Config.java entry - we can mark it as
deprecated and ignored and remove it in a future version (and you could
update Config.java to log a message about having a deprecated config
option). It's a much better operator experience: log for a major version,
then remove in the
Accidentally dropped dev@, so adding back in the dev list, with the hopes
that someone on the dev list helps address this.
On Fri, Feb 11, 2022 at 2:22 PM Jeff Jirsa wrote:
> That looks like https://issues.apache.org/jira/browse/CASSANDRA-17132 +
> https://github.com/apache/cassandra/
(This was a +1 on the release, to be clear, not a +1 on the sentiment
below, which I appreciate but still believe we should proceed with the
release)
On Tue, Feb 8, 2022 at 3:44 PM Jeff Jirsa wrote:
> +1
>
>
> On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie
> wrote:
>
>>
1 - 100 of 470 matches
Mail list logo
