[DBI-855] MySQL connector: Use binlog event type and meta to determine BINARY(N) actual length and padding#4445
Conversation
🔄 Flaky Test DetectedAnalysis: TestApiPg/TestResetMirrorSequences hit a fixed 60s polling timeout while the mirror was still in STATUS_SNAPSHOT — a timing/resource-contention flake under -p 32 parallelism, unrelated to the PR's MySQL BINARY(N) padding change. ✅ Automatically retrying the workflow |
| switch qkind { | ||
| case types.QValueKindBytes: | ||
| return types.QValueBytes{Val: shared.UnsafeFastStringToReadOnlyBytes(val)}, nil | ||
| b := shared.UnsafeFastStringToReadOnlyBytes(val) |
There was a problem hiding this comment.
looks good to me
just one thing, are we sure it comes as 'string' for all flavors/versions?
i see that we also have []byte: case a bit above
not sure if we need the same padding mechanism there just in case
There was a problem hiding this comment.
Unless I am not mistaken, []byte correspond to variable length types. In contrast BINARY[N] is fixed.
There was a problem hiding this comment.
All flavors/vers have the same implementation, linked the source
ilidemi
left a comment
ilidemi
left a comment
There was a problem hiding this comment.
There is one corner-corner case where a column gets added during CDC, we miss a DDL event then infer the type from the future binlog event metadata and it ends up going around this path but this requires enough untangling that it should be a separate task
Co-authored-by: Ilia Demianenko <[email protected]>
3 participants
MySQL BINARY(N) values are right-padded, from https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html
In MySQL binlog, these values are:
When querying the data, MySQL uses the record type and metadata to restore the original length but, when reading events from binlog directly,
Closes: DBI-855
Related to: https://github.com/ClickHouse/support-escalation/issues/8013
References: