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

Online alter fails under LOCK TABLE with ER_ALTER_OPERATION_NOT_SUPPORTED_REASON

Details

    Description

      create table t (f int);
      		 
      lock table t write;
      		 
      alter table t force, algorithm=copy, lock=none;
      		 
       
      		 
      # Cleanup
      		 
      drop table t;

      bb-10.10-MDEV-16329 cb1f08bd1c

      		 
      mysqltest: At line 3: query 'alter table t force, algorithm=copy, lock=none' failed: ER_ALTER_OPERATION_NOT_SUPPORTED_REASON (1846): LOCK=NONE is not supported. Reason: COPY algorithm requires a lock. Try LOCK=SHARED

      If it's expected, it needs to be documented.

      Attachments

        Issue Links

          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-29056 Replica SQL thread stops with 1846 error on ALTER ONLINE after LOCK WRITE

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          is caused by

          Task - A task that needs to be done. MDEV-16329 Engine-independent online ALTER TABLE

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          relates to

          Technical task - A technical task. MDEV-28808 Test MDEV-16329 (ALTER ONLINE TABLE) - Core server part

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment - - edited

            Generally, independently from algorithm, it does not make sense to specify lock=shared or lock=none under lock tables, because the table is already exclusively locked.

            the question is, should be an error "cannot use lock=xxx under lock tables"? a warning "lock=xxx has no effect under lock tables"? or keep the current behavior and silently ignore the lock=xxx clause?

            serg Sergei Golubchik added a comment - - edited Generally, independently from algorithm, it does not make sense to specify lock=shared or lock=none under lock tables , because the table is already exclusively locked. the question is, should be an error "cannot use lock=xxx under lock tables"? a warning "lock=xxx has no effect under lock tables"? or keep the current behavior and silently ignore the lock=xxx clause?
            elenst Elena Stepanova added a comment - - edited

            I don't think we can make it an error easily, at least for lock=shared it already succeeds in the existing versions, so it would be a regression, and not a very well justified one.
            A warning does make sense, I suppose.

            elenst Elena Stepanova added a comment - - edited I don't think we can make it an error easily, at least for lock=shared it already succeeds in the existing versions, so it would be a regression, and not a very well justified one. A warning does make sense, I suppose.
            nikitamalyavin Nikita Malyavin added a comment -

            ok

            nikitamalyavin Nikita Malyavin added a comment - ok

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.