The drift report has:
"ipblocks ipb_timestamp field-type-mismatch": { "s1": [ "db1083:enwiki", "db1084:enwiki", "db1169:enwiki", "db1118:enwiki", "db1163:enwiki", "db1106:enwiki", "db1164:enwiki", "db1119:enwiki", "db1134:enwiki", "db1135:enwiki" ], "s2": [ "db1122:svwiki", "db1129:svwiki", "db1076:svwiki" ], "s3": [ "db1123:aswikibooks", "db1166:aswikibooks", "db1157:aswikibooks", "db1175:aswikibooks", "db1112:aswikibooks" ], "s6": [ "db1131:ruwiki", "db1168:ruwiki", "db1085:ruwiki", "db1173:ruwiki" ], "s7": [ "db1086:cawiki", "db1174:cawiki", "db1127:cawiki", "db1079:cawiki" ] },
It's varbinary(14) in production:
wikiadmin@10.64.16.186(enwiki)> desc ipblocks; +----------------------+---------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------------+---------------------+------+-----+---------+----------------+ | ipb_timestamp | varbinary(14) | NO | MUL | NULL | | ...
But in the code it's binary(14) and has been since 2007 (was changed from char(14) in rMWf38344a) and has been in char(14) since its introduction in r498, It moved around quite a bit though: r575 and r647). I don't know why it's set to varbinary in production.
According to T42626: Standardise type of timestamp database fields (MySQL), this should be binary(14) and given the fact that this has been like that in basically any wiki made in the past decade (including wikidata), I think it's fine to assume this change would be safe.
ALTER TABLE /*_*/ ipblocks MODIFY ipb_timestamp BINARY(14) NOT NULL;
Schema change progress:
- s1
- eqiad
- codfw
- s2
- eqiad
- codfw
- s3
- eqiad
- codfw
- s4
- eqiad
- codfw
- s5
- eqiad
- codfw
- s6
- eqiad
- codfw
- s7
- eqiad
- codfw
- s10
- labtestwiki
Confirmed that s8 is not affected.