Uploaded image for project: 'Percona Toolkit'
  1. Percona Toolkit
  2. PT-1928

Add option to set lock timeouts distinctly for various statements

Details

    • Improvement
    • Status: Open
    • Medium
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

      The problem given in

      https://forums.percona.com/t/pt-online-schema-change-exiting-due-to-errors-while-restoring-triggers-dbd-db-do-failed-lock-wait-timeout-exceeded-try-restarting-transaction/8911/11

      shows that getting a table lock to finalize the migration should be more patient, otherwise lock may never be obtained.

       

      I’m not alluding to mysql’s concept of priority.
      It's a new concept of distinct tolerance to timeout among ptosc statements.

      Row copies and most throttled work can certainly use 1s lock timeout.
      However, terminating the migration with a “broad-hard-to-get full table write lock” should be willing to wait A LOT longer for a lock, so that it stands a chance of acquiring it. Otherwise, it’s very unlikely that a table lock would be obtainable in 1s on a table that sees incessant concurrent queries.

      (also: reminder on drop_swap loosing triggers (PT-1919)).

      Attachments

        Activity

          People

            Unassigned Unassigned
            bob2021 bob
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:

              Smart Checklist