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

MySQL Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.9
    • Fix Version/s: 10.0.26
    • Component/s: OTHER
    • Labels:
      None

      Description

      Test case for MySQL " Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE" fails in 10.0.

      Note that MariaDB returns proper error message. The problem is that IGNORE has no effect in multi-table update.

      Relevant revision:

      revno: 3803.1.9
      committer: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
      branch nick: mysql-trunk-11757486
      timestamp: Thu 2012-05-10 14:19:23 +0530
      message:
        Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH
                            MULTI-TABLE UPDATE
       
        Analysis:
        ---------
        Multiple-table UPDATE statement with IGNORE keyword in strict mode
        having invalid or missing values could trigger an assertion in debug
        mode. However on a release build, the query execution fails reporting
        inappropriate errors.
       
        The multiple-table UPDATE does not test for IGNORE to decide
        whether the query should be aborted in case of any warning.This causes
        the warning to be converted to error(STRICT MODE behavior). However
        since the errors are to be suppressed due to the IGNORE keyword, the
        diagnostic area is not set to DA_ERROR.
       
        Since the diagnostic area remains DA_EMPTY, an ASSERT is triggered
        which causes the mysqld to crash on a debug build. On a release build
        the query execution fails with incorrect errors being reported.
       
        Fix:
        ---
        To test for IGNORE during the execution of the multiple-table UPDATE
        statement. This causes the successful execution of the query with
        appropriate warnings being reported.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                sanja Oleksandr Byelkin
                Reporter:
                svoj Sergey Vojtovich
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: