You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by "Max C." <mc...@core43.com> on 2018/09/13 20:11:43 UTC

Corrupt insert during ALTER TABLE add

I ran “alter table” today to add the “task_output_capture_state” column (see below), and we found a few rows inserted around the time of the ALTER TABLE did not contain the same values when selected as when they were inserted.

When the row was selected, what we saw was:
- test_id —> OK (same as insert)
- test_instance_group_id —> inserted as UNSET_ID, selected it contained the same value as test_id
- test_name —> OK (same as insert)
- ti_exec_flow —> inserted as “STD”, selected it contained the same value as test_name

Does this ring a bell?  Is there a JIRA for this (hopefully fixed in a newer C*)?  We’re running 3.0.6.  Thanks everyone.

CREATE TABLE mars.test_instances_by_run_submission (
    run_submission_id timeuuid,
    rs_bucket_num int,
    id timeuuid, 
    active_task_id timeuuid,
    active_task_name_path text,
    exec_end timestamp,
    exec_gpath text,
    exec_host_id uuid,
    exec_start timestamp,
    exec_state text,
    exec_subbuild_id timeuuid,
    exec_vco text,
    fstatus text,
    grid_job_id uuid,
    legacy_assert boolean,
    legacy_core boolean,
    source_gpath text,
    task_output_capture_state text,   # NEW
    test_id uuid,
    test_instance_group_id uuid,
    test_name text,
    ti_exec_flow text,
    PRIMARY KEY ((run_submission_id, rs_bucket_num), id)
) WITH CLUSTERING ORDER BY (id ASC)

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


Re: Corrupt insert during ALTER TABLE add

Posted by "Max C." <mc...@core43.com>.
Correction — we’re running C* 3.0.8.  DataStax Python driver 3.4.1.

> On Sep 13, 2018, at 1:11 pm, Max C. <mc...@core43.com> wrote:
> 
> I ran “alter table” today to add the “task_output_capture_state” column (see below), and we found a few rows inserted around the time of the ALTER TABLE did not contain the same values when selected as when they were inserted.
> 
> When the row was selected, what we saw was:
> - test_id —> OK (same as insert)
> - test_instance_group_id —> inserted as UNSET_ID, selected it contained the same value as test_id
> - test_name —> OK (same as insert)
> - ti_exec_flow —> inserted as “STD”, selected it contained the same value as test_name
> 
> Does this ring a bell?  Is there a JIRA for this (hopefully fixed in a newer C*)?  We’re running 3.0.6.  Thanks everyone.
> 
> CREATE TABLE mars.test_instances_by_run_submission (
>    run_submission_id timeuuid,
>    rs_bucket_num int,
>    id timeuuid, 
>    active_task_id timeuuid,
>    active_task_name_path text,
>    exec_end timestamp,
>    exec_gpath text,
>    exec_host_id uuid,
>    exec_start timestamp,
>    exec_state text,
>    exec_subbuild_id timeuuid,
>    exec_vco text,
>    fstatus text,
>    grid_job_id uuid,
>    legacy_assert boolean,
>    legacy_core boolean,
>    source_gpath text,
>    task_output_capture_state text,   # NEW
>    test_id uuid,
>    test_instance_group_id uuid,
>    test_name text,
>    ti_exec_flow text,
>    PRIMARY KEY ((run_submission_id, rs_bucket_num), id)
> ) WITH CLUSTERING ORDER BY (id ASC)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: user-help@cassandra.apache.org

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


Re: Corrupt insert during ALTER TABLE add

Posted by "Max C." <mc...@core43.com>.
Yep, that’s the problem!  Thanks Jeff (and Alex Petrov for fixing it).

- Max

> On Sep 13, 2018, at 1:24 pm, Jeff Jirsa <jj...@gmail.com> wrote:
> 
> CASSANDA-13004 (fixed in recent 3.0 and 3.11 builds)

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


Re: Corrupt insert during ALTER TABLE add

Posted by Jeff Jirsa <jj...@gmail.com>.
CASSANDA-13004 (fixed in recent 3.0 and 3.11 builds)


On Thu, Sep 13, 2018 at 1:12 PM Max C. <mc...@core43.com> wrote:

> I ran “alter table” today to add the “task_output_capture_state” column
> (see below), and we found a few rows inserted around the time of the ALTER
> TABLE did not contain the same values when selected as when they were
> inserted.
>
> When the row was selected, what we saw was:
> - test_id —> OK (same as insert)
> - test_instance_group_id —> inserted as UNSET_ID, selected it contained
> the same value as test_id
> - test_name —> OK (same as insert)
> - ti_exec_flow —> inserted as “STD”, selected it contained the same value
> as test_name
>
> Does this ring a bell?  Is there a JIRA for this (hopefully fixed in a
> newer C*)?  We’re running 3.0.6.  Thanks everyone.
>
> CREATE TABLE mars.test_instances_by_run_submission (
>     run_submission_id timeuuid,
>     rs_bucket_num int,
>     id timeuuid,
>     active_task_id timeuuid,
>     active_task_name_path text,
>     exec_end timestamp,
>     exec_gpath text,
>     exec_host_id uuid,
>     exec_start timestamp,
>     exec_state text,
>     exec_subbuild_id timeuuid,
>     exec_vco text,
>     fstatus text,
>     grid_job_id uuid,
>     legacy_assert boolean,
>     legacy_core boolean,
>     source_gpath text,
>     task_output_capture_state text,   # NEW
>     test_id uuid,
>     test_instance_group_id uuid,
>     test_name text,
>     ti_exec_flow text,
>     PRIMARY KEY ((run_submission_id, rs_bucket_num), id)
> ) WITH CLUSTERING ORDER BY (id ASC)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: user-help@cassandra.apache.org
>
>