mariadb-binlog --stop-datetime truncates output to 3 header events on a relay binlog (log_slave_updates=ON) closed by rotation

Symptom

mariadb-binlog --stop-datetime=<T> <file>

On a closed relay binlog, this command outputs only the three file header events:

• Start_log_event
• Gtid_list
• Binlog_checkpoint

It silently skips every transactional event in the file, regardless of the value of T.

The bug is reproducible on a closed binlog file produced by a secondary server with log_slave_updates = ON. In that setup, events are replicated from the upstream master and then re-emitted to the local binlog.

This is distinct from MDEV-35528, which is about multi-file scans and is fixed in 10.11.11 / 11.7.2 / 11.8.x. The reproduced 11.8.7 build already contains that fix.

Affected versions

mariadb-binlog Ver 3.5 / from 10.11.16-MariaDB (BuildID dfa3536b343f...)

mariadb-binlog Ver 3.5 / from 11.8.7-MariaDB   (BuildID acd49e16280d...)

Both binaries were extracted from the official Debian 12 packages:

mariadb-client_10.11.16+maria~deb12_amd64.deb

mariadb-client_11.8.7+maria~deb12_amd64.deb

Reproduction

1. Configure a server with log_slave_updates = ON, replicating from an upstream master with workload.
2. Wait until a binlog rotates, or run FLUSH BINARY LOGS.
3. Pick a closed binlog file.
4. Run mariadb-binlog --stop-datetime against that file.

The important property of the selected file is that its trailing Binlog_checkpoint is dated at the time the file was closed, not at the time of the transactional events inside the file.

mariadb-binlog --stop-datetime='<any value past every txn>' <file>

Expected: every event whose timestamp is before stop-datetime is emitted.

Actual: only the three file header events are emitted.

Evidence

File: mariadb-bin.011945

• Size: 80 MB partial
• Source: relay running 11.8.6-MariaDB-0+deb13u1

$ mariadb-binlog <file> | grep -c '^#260513'

325397

$ mariadb-binlog --start-datetime='2026-05-13 14:00:00' <file> \

    | grep -c '^#260513'

325397    # --start-datetime works correctly

$ mariadb-binlog --stop-datetime='2099-12-31 23:59:59' <file> \

    | grep -c '^#'

3         # any --stop-datetime value returns only 3 events, even a max-future value

$ mariadb-binlog --start-position=4 --stop-position=1000000 <file> \

    | grep -c '^#'

3778      # --stop-position works correctly

Event timestamps in the file

First Start_log_event:           260513 15:03:09  (data start)

Last transactional event:        260513 15:03:57  (data end)

Final Binlog_checkpoint (queue): 260517 19:06:43  (file-close time)

The trailing Binlog_checkpoint is dated at file rotation/close time, not at transactional data time.

Suspicion: the --stop-datetime scanner consults this trailing event up front, sees that it is past the requested stop time, and triggers the stop heuristic before emitting the transactional payload.

Distribution of end_log_pos in the file

In row-based binlogs forwarded through log_slave_updates, intermediate transaction events such as Table_map, Write_rows, Update_rows and Delete_rows carry end_log_pos = 0. Only Query events such as BEGIN / COMMIT carry a real position.

events with end_log_pos = 0   : 222507  (Table_map + row events)

events with end_log_pos != 0  : 102890  (GTID + Query)

Total events in file          : 325397

Workaround

Do not pass --stop-datetime to mariadb-binlog for this relay-binlog case. Instead, emit the binlog without that option and filter by header timestamp in the consumer.

Impact

• Point-in-time recovery scripts that target a relay binlog with --stop-datetime can silently skip the entire payload.
• Tooling that performs binlog analysis against relay files, such as pmacontrol/BinlogAnalyzer, reports zero transactions for the selected window.

I can send the offending 80 MB binlog file privately if needed.