Suggestion from Guilhem: Potential problem: in the binary log, we encode in 4 bytes values ("end_log_pos" for example) which can theoretically be a number larger than 2^32. So there is a risk for truncation during storing. Consequences of this truncation are not well known. Probability: so far we got no bug reports. As RAMs get larger, transactions get larger, so users may set --max-binlog-cache-size and --binlog-cache-size to multi-GB values, making the problem more likely. The introduction of row-based replication, which creates much bigger binlog objects (a CREATE SELECT over a 10GB table creates a 10GB object), also makes the problem more likely. Proposal: review the existing code to understand the consequences of truncation, and what simple measures can be taken to avoid truncation (put a hard-coded limit on max_binlog_cache_size? add a few if()s in code?); also review if the IO_CACHE implementation (which is used by binary logging and which is years old) is ready for caches larger than 4GB. Regarding bug reports, there is one. It is bug #11762618 from new bug system, or #55231 from bugs.mysql.com. This bugs fully justifies this WorkLog entry, as well as WL # 6009. Both are based on the current constraint of 4 byte offset values. Estimated time: 6 work days.