cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
Date Fri, 06 Oct 2017 14:05:01 GMT


Sylvain Lebresne commented on CASSANDRA-13813:

bq. I don't believe it's reasonable to keep bugs in the codebase just because they mask out
other bugs.

Just to make sure my position is clear, I'm not suggesting we leave this ticket unsolved.
What I'm suggesting is that it would be possible to forbid truly harmful changes (droping
tables and adding/removing/renaming columns; that part is the real bug to me) while still
allowing the altering of table parameters (which actually don't seem that problematic to me
on principle). Sure, it requires adding some special casing in {{AlterTableStatement}}, but
it's not very complex either.

bq. when their cluster are unable to pick up our altered defaults, because of our bumped hardcoded
timestamps being smaller than the new ones set via ALTER TABLE

I'm not sure I understand the problem. If user have manually and knowingly updated some table
params, my guess is that they expect (even rely on) future changes to defaults to not override
their changes. Isn't the whole point why we've picked 0 for our hardcoded timestamp in fact?

But if there is genunine reason I'm missing that make it dangerous for user to alter those
parameters, that's certainly important to  understand.  I'm pretty sure some user _have_ done
it (at least to work around CASSANDRA-12701, possibly for other reasons), and if their change
is a time-bomb, we kind of owe them to disarm that bomb.

But anyway, to sum it up, the patch lgtm from a technical level, and I'm definitively on board
with forbidding clearly harmful changes. The only specific part I'm unsure is the "altering
table parameters" part. In light of my current understanding, it doesn't look obviously harmful
(I can even see it being desirable if I'm being honest), so I'm uncomfortable removing the
ability in a minor release.

Happy to gather a few other opinions though and if the concensus is that the patch is fine
the way it currently is, no problem, not trying to veto this in any way.

> Don't let user drop (or generally break) tables in system_distributed
> ---------------------------------------------------------------------
>                 Key: CASSANDRA-13813
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Distributed Metadata
>            Reporter: Sylvain Lebresne
>            Assignee: Aleksey Yeschenko
>             Fix For: 3.0.x, 3.11.x
> There is not currently no particular restrictions on schema modifications to tables of
the {{system_distributed}} keyspace. This does mean you can drop those tables, or even alter
them in wrong ways like dropping or renaming columns. All of which is guaranteed to break
stuffs (that is, repair if you mess up with on of it's table, or MVs if you mess up with {{view_build_status}}).
> I'm pretty sure this was never intended and is an oversight of the condition on {{ALTERABLE_SYSTEM_KEYSPACES}}
in [ClientState|].
That condition is such that any keyspace not listed in {{ALTERABLE_SYSTEM_KEYSPACES}} (which
happens to be the case for {{system_distributed}}) has no specific restrictions whatsoever,
while given the naming it's fair to assume the intention that exactly the opposite.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message