Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

Any update on this ?If there are no updates, I wonder if we can start a new update on the VOTE thread. guo Maxwell 于2024年11月5日周二 19:23写道： > Hello, everyone. > I have a point of view that our CREATE TABLE LIKE grammar should not > support the setting of table options, like : > >> CREATE TABLE cyc

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote: > Hi Everyone, > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: CEP-37 Repair Scheduling Inside Cassandra >

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Tue, Nov 5, 2024 at 2:32 PM Brandon Williams wrote: > +1 > > Kind Regards, > Brandon > > On Tue, Nov 5, 2024 at 3:28 PM Jaydeep Chovatia > wrote: > > > > Hi Everyone, > > > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed.

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 Kind Regards, Brandon On Tue, Nov 5, 2024 at 3:28 PM Jaydeep Chovatia wrote: > > Hi Everyone, > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: CEP-37 Repair Scheduling Inside Cassandra > Discussion thread: >

Re: Backporting CASSANDRA-17812 to 4.x

+1 on back porting it > On Nov 5, 2024, at 8:51 AM, Štefan Miklošovič wrote: > > Backporting in such a way that all auth requests will still go to the same > request executor as before is OK for me. > > On Tue, Nov 5, 2024 at 3:32 PM J. D. Jordan > wrote: >>

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 (non binding) > On Nov 5, 2024, at 1:28 PM, Jaydeep Chovatia > wrote: > > Hi Everyone, > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: CEP-37 Repair Scheduling Inside Cassandra >

Re: [VOTE] CEP-37: Repair scheduling inside C*

As per the CEP process documentation, this vote will be open for 72 hours > (longer if needed). > +1

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Tue, Nov 5, 2024 at 1:28 PM Jaydeep Chovatia wrote: > Hi Everyone, > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: CEP-37 Repair Scheduling Inside Cassandra >

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 > On Nov 5, 2024, at 1:34 PM, Mick Semb Wever wrote: > > > >> As per the CEP process documentation, this vote will be open for 72 hours >> (longer if needed). > > > > > +1

[VOTE] CEP-37: Repair scheduling inside C*

Hi Everyone, I would like to start the voting for CEP-37 as all the feedback in the discussion thread seems to be addressed. Proposal: CEP-37 Repair Scheduling Inside Cassandra Discussion threa

Re: Unexplained stuck memtable flush

> 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

Re: Backporting CASSANDRA-17812 to 4.x

Backporting in such a way that all auth requests will still go to the same request executor as before is OK for me. On Tue, Nov 5, 2024 at 3:32 PM J. D. Jordan wrote: > If I read the ticket correctly, this is preventing bcrypt of incoming > credentials from causing a DOS? > I think that’s reason

Re: Backporting CASSANDRA-17812 to 4.x

If I read the ticket correctly, this is preventing bcrypt of incoming credentials from causing a DOS?I think that’s reasonable to backport.  If we want to be conservative it could be backported with added code that keeps the current behavior by default?On Nov 5, 2024, at 7:43 AM, Josh McKenzie wro

Re: Backporting CASSANDRA-17812 to 4.x

I'm neutral to the backport. In terms of the letter of the law, I can see the argument either way of it being an improvement or a bugfix. Definitely wouldn't -1 a backport. On Tue, Nov 5, 2024, at 7:23 AM, Mick Semb Wever wrote: > Can you please put the ticket description in the email. Saves us

Re: Backporting CASSANDRA-17812 to 4.x

Can you please put the ticket description in the email. Saves us having to follow the link to know what you're talking about. Yes to backporting this. On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič wrote: > Hello, > > I want to ask if there are objections for backporting CASSANDRA-17812 (1) >

Unexplained stuck memtable flush

Hi all, We have a cluster running Cassandra 4.1.1. We are seeing the memtable flush randomly getting stuck. This has happened twice in the last 10 days, to two different nodes in the same cluster. This started to happen after we enabled CDC, and each time it got stuck, there was at least one

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

Hello, everyone. I have a point of view that our CREATE TABLE LIKE grammar should not support the setting of table options, like : > CREATE TABLE cycling.cyclist_name4 LIKE cycling.cyclist_name WITH TRIGGERS > AND VIEWS AND compaction = { 'class' : 'LeveledCompactionStrategy' } AND > default_time_

Re: [DISCUSS] Usage of "var" instead of types in the code

To me, this sounds like the style consistency throughout the project, so if we just allowed having the "var" keyword we would have a mix of new and old styles without any distant prospect of a unified style. We should evolve the code style from one unified form to another, thus either we use it ev

Backporting CASSANDRA-17812 to 4.x

Hello, I want to ask if there are objections for backporting CASSANDRA-17812 (1) to 4.0.x and 4.1.x. There is a question already in that ticket about backporting from another person and we keep being asked about this a lot. It seems to me that while this is technically an improvement, it is so va