Comment 7 for bug 1215587

Good day Frank

I applied your patch and after it initially looked like it solved the issue, I realised a related problem still exists.

There could be two types of foreign key constraints related to a table that needs to be altered using pt-online-schema-change:
 1) A FK on this table referencing another table.
 2) A FK on another table referencing the table to be altered.

The patch provided by yourself addresses and fixes one of these scenarios, the second one. The FK in scenario 1 has a name that gets prepended with underscores all the time until the name gets too long and breaks. This of course is a problem.

The following example demonstrates this behaviour:

// ----- Create two test tables with FKs for scenario 1 and 2: -----
drop database if exists test_db;
CREATE DATABASE test_db;
USE test_db;

CREATE TABLE IF NOT EXISTS `Table1` (
  `ID` int unsigned NOT NULL AUTO_INCREMENT,
  `T2ID` smallint unsigned DEFAULT NULL,
  PRIMARY KEY (`ID`),
  KEY `tagIndex` (`T2ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=335;

CREATE TABLE `Table2` (
  `ID` smallint unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=335;

ALTER TABLE `Table1`
  ADD CONSTRAINT `fkey1` FOREIGN KEY (`T2ID`) REFERENCES `Table2` (`ID`) ON DELETE NO ACTION;

ALTER TABLE `Table2`
  ADD CONSTRAINT `fkey2` FOREIGN KEY (`ID`) REFERENCES `Table1` (`T2ID`) ON DELETE NO ACTION;

// ----- Check the constraint names. -----
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE table_schema='test_db' and (table_name='Table1' OR table_name='Table2') and CONSTRAINT_NAME LIKE '%fkey%';

Here you will see the names of both FKs being:
 1) 'fkey1'
 2) 'fkey2'.

So far so good.

// ---- Now alter the first table 'Table1' using pt-online-schema-change which had been patched: -----
./pt-online-schema-change-2.2.6-PATCHED --alter-foreign-keys-method=rebuild_constraints --execute -u 'username' --password='password' D='test_db',t='Table1' --alter='ENGINE=InnoDB'

After this alter had been run 5 times, the constraint names are:
 1) '_____fkey1'
 2) '_fkey2'

The name of the second FK is managed correctly where the underscores are added and removed from run to run.

However, the name of the first FK is prepended with underscores every run and eventually will break when it gets too long.

I tested this behaviour with your patch applied to versions 2.2.6, 2.2.7 and 2.2.8 of the Debian installers available online and all have the same behaviour in this regard.

Looking forward to your feedback.

Regards
Francois