Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 28 Aug 2017 07:35:01 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13097875.1503897904000.133902.1503905701775@Atlassian.JIRA>
In-Reply-To: <JIRA.13097875.1503897904000@Atlassian.JIRA>
References: <JIRA.13097875.1503897904000@Atlassian.JIRA> <JIRA.13097875.1503897904156@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13812) Missing system keyspace tables
 are not created
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 28 Aug 2017 07:35:08 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-13812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143479#comment-16143479 ] 

Sylvain Lebresne commented on CASSANDRA-13812:
----------------------------------------------

Ping [~jjirsa] and [~iamaleksey]. It seems using a fixed timestamp of 0 was intended by CASSANDRA-13441, and I didn't saw that at the time, but I'm not 100% of the reasoning. It feels like this basically makes it impossible for use to update any parameters on system distributed tables (worst, if we do update them, the new values may or may not be picked up depending on how the old and new value are resolved (since they will have the same timestamp), which makes for an bug that feels easy to go undetected). And in case where whatever new value we're set doesn't get picked up, this also mean the code in {{StorageService.maybeAddOrUpdateKeyspace}} would try to re-update the table on every start without success.

I will note that example in the description is a bit debatable in the sense that the fact we actually allow dropping {{system_distributed}} is imo a bug in the first place. A bug we should fix and I created CASSANDRA-13813 for that. But as said above, even outside that particular case, CASSANDRA-13441 means (unless I'm missing something) that we cannot ever do any update to a {{system_distributed}} table (we can add stuffs, but we can't update) and that doesn't feel ideal to me. Even more so because the restriction is kind of silent right now and could be easily overlook in future updates.

> Missing system keyspace tables are not created
> ----------------------------------------------
>
>                 Key: CASSANDRA-13812
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13812
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Distributed Metadata
>            Reporter: ZhaoYang
>
> Auth/Trace/Distributed Keyspaces or Tables dropped are not created on startup although a log message {{MigrationManager.java:220 - Create new table: TableMetadata...}} appears.
> Steps to reproduce:
> # Start node
> # {{DROP TABLE system_distributed.view_build_status;}}
> # {{DROP TABLE system_distributed.repair_history;}}
> # Stop node
> # Start node
> # Tables are *not* created, but log messages appear
> Cause:
> System's keyspaces or tables are created with timestamp 0 in CASSANDRA-13441


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org