... ok apparently shift+enter sends messages now?
I was just saying if at least the file format AND system/tables - anything
written to disk - can be protected with a switch, then it allows for quick
downgrade by shutting down the entire cluster and restarting with the
downgraded binary. It's a s
Just this once I'm going to be really brief :-)
Just wanted to share for reference how Mongodb implemented downgradeability
around their 4.4 version:
https://www.mongodb.com/docs/manual/release-notes/6.0-downgrade-sharded-cluster/
Jeff you're right. Ultimately this is about more than file formats
Those tickets mostly do not need to break compatibility, and it is pretty easy for them to avoid doing so without any additional facilities.Only the TTL ticket has an excuse, as it debatably needs to support a higher version under certain non-default config settings. However there are no serialisat
We have multiple tickets about to merge that introduce new on disk format
changes. I see no reason to block those indefinitely while we figure out how
to do the on disk format downgrade stuff.
-Jeremiah
> On Feb 22, 2023, at 3:12 PM, Benedict wrote:
>
> Ok I will be honest, I was fairly sure
Ok I will be honest, I was fairly sure we hadn’t yet broken downgrade - but I was wrong. CASSANDRA-18061 introduced a new column to a system table, which is a breaking change. But that’s it, as far as I can tell. I have run a downgrade test successfully after reverting that ticket, using the one li
I guess back to the point of the thread, we need a way to know what configs are
mutable for the settings virtual table, so need some way to denote that the
config replica_filtering_protection.cached_rows_fail_threshold is mutable.
Given the way that the yaml config works, we can’t rely on the p
I suppose it can be easy for the existing feature branches if they have a
single commit. Don't we need to adjust each commit for multi-commit feature
branches?
śr., 22 lut 2023, 19:48 użytkownik Maxim Muzafarov
napisał:
> Hello everyone,
>
> I have created an issue CASSANDRA-18277 that may help
Hello everyone,
I have created an issue CASSANDRA-18277 that may help us move forward
with code style changes. It only affects the way we store the IntelliJ
code style configuration and has no effect on any current (or any)
releases, so it should be safe to merge. So, once the issue is
resolved, e
> why not implement backwards write compatibility?
+1 to this from a philosophical perspective. Keeping prior releases completely
in the dark about new release sstable formats is a clean approach, and we
should already have the code around to ser/deser the prior version's data on
the next versio
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
> 1. Major SSTable changes should begin with forward-compatibility in a
prior release.
This requires "feature" changes, i.e. new non-trivial code for previous
patch releases. It also entails porting over any further format
modification.
Instead of this, in combination with your second point, why
Could you describe the issues? Config that is globally exposed should ideally be immutable with final members, in which case volatile is only necessary if you’re using the config parameter in a tight loop that you need to witness a new value - which shouldn’t apply to any of our config.There are so
Could maybe be an issue for some really tight unit tests. In actual use the
updates to those fields will be globally visible near instantly without
volatile keyword.
> On 22 Feb 2023, at 13:17, Benjamin Lerer wrote:
>
> I have seen issues with some updatable parameters which were missing the
I have seen issues with some updatable parameters which were missing the
volatile keyword.
Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko a
écrit :
> FWIW most of those volatile fields, if not in fact all of them, should NOT
> be volatile at all. Someone started the trend and most folks have
Close. It is still in the table so the v3.x code that reads system.local
will detect it and fail on an unknown column as that code appears to be
looking at the actual on-disk format.
It sounds like the short answer is that there is no way to physically
remove the column from the on-disk format on
When a column is dropped from a table, it is added to the
system.dropped_columns table so it doesn't get returned in the results. Is
that what you mean? 🙂
>
Greetings,
I have been looking through the code and I can't find any place where
columns are removed from an sstable. I have found that rows can be
deleted. Columns can be marked as deleted. But I have found no place
where the deleted cell is removed from the row. Is there the concept of
comp
FWIW most of those volatile fields, if not in fact all of them, should NOT be
volatile at all. Someone started the trend and most folks have been copycatting
or doing the same for consistency with the rest of the codebase.
Please definitely don’t rely on that.
> On 21 Feb 2023, at 21:06, Maxim
18 matches
Mail list logo
