On Dec 22, Alexander Barkov wrote:
Hi Sergei, Kristian,
So, there are a lot of details in that bug and in the discussion, and I did not get a full overview of the problem, or what you were asking from me, but I'll try to answer as best I can. Do I understand correctly that row-based replication writes directly the internal representation of a DECIMAL column into the binlog event, without marking whether it is the old (pre-5.0) or the new format? That indeed seems unfortunate. But I tend to agree that this is not something to try fixing, giving that this is a problem from 4.x days. I would however suggest that in 10.1, we give an error on an attempt to binlog a row-based event with the old-format DECIMAL. The error should explain that the table needs to be converted to the new format to work with row-based replication.
I think that CHECK TABLE..FOR UPDATE should report the problem with long DECIMALs in a warning. mysql_upgrade should also warn about the problem, but should not touch these tables.
I think that sounds reasonable. I assume that fixing the internal types requires a full table rebuild? Full table rebuild can be extremely painful on large tables. So it is rather dangerous to add that in a minor stable release. For example, the Debian/Ubuntu packages run mysql_upgrade automatically, and minor stable releases arrive as security fixes. So one could argue for fixing in 10.1 from this point of view. Maybe / hopefully, given that this is a pre-5.0 problem, the issue is not _that_ important one way or the other. - Kristian.