An error occurred fetching the project authors.
  1. 24 May, 2021 1 commit
    • Monty's avatar
      Speed up atomic test suite by improving wait_until_connected_again.inc · e5b6db01
      Monty authored
      and remove usage of RESET MASTER in loops.
      
      - Remove sleep of 0.1 second that was done even when not needed.
      - Don't call include/wait_wsrep_ready.inc if NO_WSREP is defined.
      - Added NO_WSREP=1 to all atomic tests.
      - Use 'select 1' instead of 'show status' to check is server is up.
      - Changed RESET MASTER to FLUSH BINARY LOGS to speed up atomic tests.
        To be able to do this, added a new parameter variable to
        show_events.inc to allow one to specify the name of the binary log
        in the output.
      e5b6db01
  2. 19 May, 2021 3 commits
    • Monty's avatar
      MDEV-24746 Atomic CREATE TRIGGER · ffe7f19f
      Monty authored
      The purpose of this task is to ensure that CREATE TRIGGER is atomic
      
      When a trigger is created, we first create a trigger_name.TRN file and then
      create or update the table_name.TRG files.
      This is done by creating .TRN~ and .TRG~ files and replacing (or creating)
      the result files.
      
      The new logic is
      
      - Log CREATE TRIGGER to DDL log, with a marker if old trigger existsted
      - If old .TRN or .TRG files exists, make backup copies of these
      - Create the new .TRN and .TRG files as before
      - Remove the backups
      
      Crash recovery
      - If query has been logged to binary log:
        - delete any left over backup files
      - else
         - Delete any old .TRN~ or .TRG~ files
         - If there was orignally some triggers (old .TRG file existed)
            - If we crashed before creating all backup files
               - Delete existing backup files
            - else
               - Restore backup files
            - end
         - Delete .TRN and .TRG file (as there was no triggers before
      
      One benefit of the new code is that CREATE OR REPLACE TRIGGER is now
      totally atomic even if there existed an old trigger: Either the old
      trigger will be replaced or the old one will be left untouched.
      
      Other things:
      - If sql_create_definition_file() would fail, there could be memory leaks
        in CREATE TRIGGER, DROP TRIGGER or CREATE OR REPLACE TRIGGER.  This
        is now fixed.
      ffe7f19f
    • Monty's avatar
      MDEV-24395 Atomic DROP TRIGGER · 407e9b78
      Monty authored
      The purpose of this task is to ensure that DROP TRIGGER is atomic.
      
      Description of how atomic drop trigger works:
      
      Logging of DROP TRIGGER
          Log the following information:
          db
          table name
          trigger name
          xid /* Used to check if query was already logged to binary log */
          initial length of the .TRG file
          query if there is space for it, if not log a zero length query.
      
      Recovery operations:
      - Delete if exists 'database/trigger_name.TRN~'
        - If this file existed, it means that we crashed before the trigger
          was deleted and there is nothing else to do.
      - Get length of .TRG file
        - If file length is unchanged, trigger was not dropped. Nothing else to
          do.
      - Log original query to binary, if it was stored in the ddl log. If it was
        not stored (long query string), log the following query to binary log:
        use `database` ; DROP TRIGGER IF EXISTS `trigger_name`
        /* generated by ddl log */;
      
      Other things:
      - Added trigger name and DDL_LOG_STATE to drop_trigger()
        Trigger name was added to make the interface more consistent and
        more general.
      407e9b78
    • Monty's avatar
      MDEV-23844 Atomic DROP TABLE (single table) · e3cfb7c8
      Monty authored
      Logging logic:
      - Log tables, just before they are dropped, to the ddl log
      - After the last table for the statement is dropped, log an xid for the
        whole ddl log event
      
      In case of crash:
      - Remove first any active DROP TABLE events from the ddl log that matches
        xids found in binary log (this mean the drop was successful and was
        propery logged).
      - Loop over all active DROP TABLE events
        - Ensure that the table is completely dropped
      - Write a DROP TABLE entry to the binary log with the dropped tables.
      
      Other things:
      - Added code to ha_drop_table() to be able to tell the difference if
        a get_new_handler() failed because of out-of-memory or because the
        handler refused/was not able to create a a handler. This was needed
        to get sequences to work as sequences needs a share object to be passed
        to get_new_handler()
      - TC_LOG_BINLOG::recover() was changed to always collect Xid's from the
        binary log and always call ddl_log_close_binlogged_events(). This was
        needed to be able to collect DROP TABLE events with embedded Xid's
        (used by ddl log).
      - Added a new variable "$grep_script" to binlog filter to be able to find
        only rows that matches a regexp.
      - Had to adjust some test that changed because drop statements are a bit
        larger in the binary log than before (as we have to store the xid)
      
      Other things:
      - MDEV-25588 Atomic DDL: Binlog query event written upon recovery is corrupt
        fixed (in the original commit).
      e3cfb7c8