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 Mon, 09 Oct 2017 13:05:00 GMT


Sylvain Lebresne commented on CASSANDRA-13813:

bq.  But the way ALTER works, we serialise the whole table, including all params and all columns

Good point, I hadn't though about that part. Sad!

So I guess I would agree in principle about shielding user against clearly dysfunctional behaviors.
The problem is that in practice I know for a fact that CASSANDRA-12701 has been an issue for
some users, where the tables had been growing way too much, to the point that being able to
work-around that by setting a TTL manually probably override concerns about hypothetical future
changes to defaults not being picked up.

Or to put it another way, none of this is ideal, but I wonder is "repair history tables regularly
grows out of control regularly" isn't a bigger problem in practice than "future defaults changes
to system tables may not be picked up". Anyway, again, not opposed on the current patch personally,
but uneased by it, so wouldn't mind a few additional opinion to see if it's just me being
difficult (which is possible).

> 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