Thx for the report!

We need to add Mysql 5.7 support in our Long Term Support release, added to 2.15.1: #6642

Presumably, the generated label is usable for debugging, especially in those edge cases where a lock blocks for a long time, then the server goes away, and some dba needs to clean it up. (At least, it might work on innodb tables.) My md5() workaround clobbers the utility of such code. That code is here: core/Model.php:284.

        $dbLockName = "deletePreviousArchiveStatus.$numericTable.$archiveId";

The problem is this: the code is completely MySQL-specific. Acquiring a "named" table lock is MySQL specific, (as is the need for table locks, in general), so to abstract from the db-engine, you'd need to push the name-generation down a level, into the Db-handler code itself. I'm not here today to preach the glorious benefits of using postgresql over mysql, so let's assume it will remain mysql-specific for the near future.

So while we're still talking MySQL-specific code, and since it's MySQL that forces us now to restrict this call to 64 characters, let's shorten it in a reasonable but mysql-specific way. Let me suggest: (1) use hex-encoded archiveID, (2) abbreviate the module prefix name.

The archiveID for that table type (see Db/Schema/Mysql.php) is an unsigned integer, or 4-bytes, or 8-hex chars. We explicate the length of the other fields, leaving up to 40 characters for the name of the table.

    // Ensure compat with 5.7.5+ : max 64-char get_lock() label
    $dbLockName = sprintf("%.14s.%.40s.%08x",
            "delPrvArcvStat", # 14 chars
            $numericTable,
            intval($archiveId)
    );

Is this enough to expedite progress, or should I generate an actual patch?

My PHP isn't that great, but maybe instead of relying on sprintf's precision, it makes more sense to do something like:

 substr($numericTable, -40, 40),

in order to make sure the lock identifies the most distinctive part of the table name.

Marked as duplicate of #6642 - edit: keeping this one open as well as it is more clear

@tsteur thank you for addressing this. Your patch does appear to solve the problem very thoroughly.

I don't want to sound presumptuous in addressing the following point on coding style: The fix in core/DataAccess/Model.php has a hard-coded constant of 23 without explanation whatsoever. I'm sure string interpolation in PHP is fast enough, but for clarity, might I suggest using sprintf with constants, ala #9131 (comment) ? Also, given the relative opacity of these MySQL archiveIDs, does it hurt to convert to hex?

See bc4013e#diff-f0dc4d4d133f84005fcebc1e10f155c0

and also see #9395

tyvm