Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14837

Duplicate primary keys are allowed after ADD COLUMN / UPDATE

Details

    Description

      --source include/have_innodb.inc
      		 
       
      		 
      CREATE TABLE t1 (pk VARCHAR(3) PRIMARY KEY) ENGINE=InnoDB;
      		 
      INSERT INTO t1 VALUES ('foo');
      		 
      ALTER TABLE t1 ADD COLUMN f INT;
      		 
      UPDATE t1 SET f = 1;
      		 
      --error ER_DUP_ENTRY
      		 
      INSERT INTO t1 VALUES ('foo',NULL);
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1;

      The test fails on INSERT, because it actually succeeds instead of producing the expected ER_DUP_ENTRY.

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14840 Assertion `!log->same_pk' failed in row_log_table_apply_delete

          • Major - Major loss of function.
          • Closed
          is caused by

          Task - A task that needs to be done. MDEV-11369 Instant add column for InnoDB

          • Major - Major loss of function.
          • Closed
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14473 Assertion `rec_get_trx_id(rec, clust_index) < trx->id' failed in row_merge_read_clustered_index on ADD FULLTEXT KEY

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14897 After UPDATE of instant ADD COLUMN, PRIMARY KEY accepts duplicates

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14068 Assertion `0' failed in row_sel_get_clust_rec_for_mysql(row_prebuilt_t*, dict_index_t*, const rec_t*, que_thr_t*, const rec_t**, ulint**, mem_heap_t**, const dtuple_t**, mtr_t*)

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            The bug does not seem to affect ROW_FORMAT=REDUNDANT tables or PRIMARY KEY on fixed-length columns. VARCHAR(1) is the simplest key with which I reproduced the corruption.

            marko Marko Mäkelä added a comment - The bug does not seem to affect ROW_FORMAT=REDUNDANT tables or PRIMARY KEY on fixed-length columns. VARCHAR(1) is the simplest key with which I reproduced the corruption.
            marko Marko Mäkelä added a comment -

            The condition in the function row_ins_clust_index_entry_low() to check for duplicates fails to hold, because up_match=low_match=0:

            	if (n_uniq
            		 
            	    && (cursor->up_match >= n_uniq || cursor->low_match >= n_uniq)) {

            The bug is that the length of the PRIMARY KEY column is being read from the wrong offset here:

            	case REC_LEAF_COLUMNS_ADDED:
            		 
            		/* We would have !index->is_instant() when rolling back
            		 
            		an instant ADD COLUMN operation. */
            		 
            		nulls -= REC_N_NEW_EXTRA_BYTES;
            		 
            		if (rec_offs_n_fields(offsets) <= n_fields) {
            		 
            			goto ordinary;
            		 
            		}
            		 
            		/* fall through */

            If I manually set nulls-- then the correct length will be returned and the duplicate will be returned.
            Due to the bug, we are reading the incorrect length 0 from the incorrect offset.

            marko Marko Mäkelä added a comment - The condition in the function row_ins_clust_index_entry_low() to check for duplicates fails to hold, because up_match=low_match=0 : if (n_uniq && (cursor->up_match >= n_uniq || cursor->low_match >= n_uniq)) { The bug is that the length of the PRIMARY KEY column is being read from the wrong offset here: case REC_LEAF_COLUMNS_ADDED: /* We would have !index->is_instant() when rolling back an instant ADD COLUMN operation. */ nulls -= REC_N_NEW_EXTRA_BYTES; if (rec_offs_n_fields(offsets) <= n_fields) { goto ordinary; } /* fall through */ If I manually set nulls-- then the correct length will be returned and the duplicate will be returned. Due to the bug, we are reading the incorrect length 0 from the incorrect offset.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.