mizioumt

I attempted to gh-ost ALTER a one row table with \xE1 already in the original table. This finished fine. So this sort of character is properly handled by gh-ost when...

the table description is too long and I can't guess what stuff is more essential than whichever other stuff. So here's the entire thing: ``` *************************** 1. row *************************** Table:...

the table structure is real but the ALTER is not. I'm just testing gh-ost. I think this character bug will happen for any alter, even for a noop one as...

no, on this one I always had log slave updates. In particular, when I browsed through the binlogs for the last reoccurrence I saw record for the offending `id` for...

replicationwise this is a sibling of the host from #287 however on this one MySQL version is lower ``` select @@version,@@log_slave_updates; +------------+---------------------+ | @@version | @@log_slave_updates | +------------+---------------------+ | 5.6.33-log...

I think my problem is kind of independent from problem reported by @jeisen. My problem is that gh-ost refuses to handle at least one character that does belong to latin1:...

reproduces with 1.0.28, will try to find time to create a simple testcase

looks like to get a simple testcase is not as easy as I thought...

- we do SET NAMES utf8mb4 upon connection - the table structures are identical, the tables have DEFAULT CHARSET=latin1, the column is defined as simply 'text'

I found out a little more about the application: - column T1.c1 is utf8mb4, column T2.c2 is latin1 - a value is inserted into T1.c1 that contains the offending character...