← Back to team overview

maria-developers team mailing list archive

Re: Row-based replication of old DECIMAL to new DECIMAL


Hi Kristian,

On 12/23/2014 02:08 PM, Kristian Nielsen wrote:
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?

RBR does mark that this is the old pre-5.0 format.
so the slave knows that it is an old DECIMAL.

But it does not know which exactly DECIMAL(M,N),
because M and N are not available.

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

Good idea.

I'd also do the same with the old TIME/DATETIME/TIMESTAMP types with
fractional precision, as they have the same problem.

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.

Perhaps we chould fix this in 10.1, and add an error in earlier versions on attempt to RBR-binlog a table with the old DECIMAL.

  - Kristian.

Follow ups