Bug #83376 Fix for 19218794 didn't cleanup workarounds in dict_mem_create_temporary_table()
Submitted: 13 Oct 2016 16:51 Modified: 14 Oct 2016 14:08
Reporter: Sergey Vojtovich Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.7 OS:Any
Assigned to: CPU Architecture:Any

[13 Oct 2016 16:51] Sergey Vojtovich
Commit https://github.com/mysql/mysql-server/commit/de3210fdae9938eb95691fada9c58a2959bae7fb introduced reasonable solution for stale InnoDB tablespaces.

However it didn't cleanup old workarounds that were supposed to reduce probability of the same problem, specifically changes to dict_mem_create_temporary_table() don't seem to be of any value anymore. See:

The latter change is especially problematic:
- even though it is out of hot path, it adds heavyweight full memory barrier (whereas relaxed memory order is enough) along with heavyweight atomic read-modify-write without any good reason
- it also updates shared variable (potential scalability bottleneck) whereas code is supposed to generate name for a temporary table (which is thread local thing)
- there is harmless race condition: multiple threads may get same "randomly distributed number" because there's a gap between dict_temp_file_num increment and time when it is actually used

How to repeat:
No user visible effect yet. See dict_mem_create_temporary_tablename().

Suggested fix:
Revert changes to dict_mem_create_temporary_tablename() introduced by forementioned revisions.
[14 Oct 2016 14:04] MySQL Verification Team

I have analyzed thoroughly, both the fix and the workarounds. I think that you are right that workarounds are not needed, but I do not find the second patch so drastically inhibiting as you described.

However, I do agree with S3 severity.

[14 Oct 2016 14:08] Sergey Vojtovich
Sinisa, thanks for prompt reply! You're right. I should've noted that the second change doesn't seem to be inhibiting at the moment, but has potential to become such.