----- Original Message -----
Hi, Alexander!
On Dec 22, Alexander Barkov wrote:
Hi Sergei, Kristian,
I'm looking at:
MDEV-7268 Column of table cannot be converted from type 'decimal(0,?)' to type ' 'decimal(10,7)'
This bug cannot be fixed in general case, because the old DECIMAL data type does not write its metadata into the binary log.
I suggest we don't fix replication of old DECIMAL (neither binlogging, nor slave-side).
I think that's reasonable. But then CHECK TABLE ... FOR UPGRADE should issue a warning for old DECIMAL columns.
That would be nice. It took diffing a frm file to suspect it was really old decimal.
Instead, we fix "ALTER TABLE ... FORCE" (and thus mysql_upgrade) to force changing old DECIMAL to new DECIMAL. Currently, "ALTER TABLE...FORCE" preserve old DECIMAL.
If this could go in the release notes I'd really appreciate it. I'll try remember to write it there too. A long running alter table on a production upgrade that won't show up on a test slave (if set up from mysqldump) is a rather ugly surprise.
Not sure which version is best to fix in. The complainer had problems with 5.5.
I don't know, I'd say 10.0.
It was 5.5 as per the complaint.
For the complainer there's a workaround - I'm sure you can come up with an ALTER TABLE that changes columns from old to new DECIMAL, may be something like ALTER TABLE xxx MODIFY COLUMN yyy DECIMAL(....)
Given ALTER TABLE ... FORCE didn't change it I'm not why this would. I can copy/paste a show create table however or use pt-online-schema-change/pt-archiver without replication with global binlog_format set to SBR in the mean time and hopefully that covers all the buggy edge cases that trigger rather abrupt production failures. -- Daniel Black, Complainer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.