maria-developers team mailing list archive

[Daniel Black <daniel.black@xxxxxxxxxxxxx>]

----- 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.