bt-layer-measure pins a text difference by measuring the controls: at a
position they vary, the free region between their common prefix and suffix must
be one length, within a cap, and in the character class they used there. A
binary gets no such pin, because bytes carry no shape, so a coincidence in
position and magnitude is overlapping and has to be cleared by hand.
The mariadb gate run of 2026-09-28 shows what that costs. 32 of 167 differing
state paths come out real, almost all *.MAI, and the reason is one field.
Bytes 180 to 183 of an Aria index header, one based, are a four byte big endian
integer:
control 1790574106 0x6ab9fe1a
control-again 1790574278 0x6ab9fec6
control-third 1790574436 0x6ab9ff64
unit 1790574596 0x6aba0004
steps: 172, 158, 160
1790574106902134 / 10^6 is 1790574106, and that numerator is user.frm's
microsecond timestamp in the same directory, so the field is a wall clock
Unix second and SOURCE_DATE_EPOCH does not touch it. It moves in every
build, and the unit's value crossed into byte 181 where the three controls had
not, so it differs outside the floor.
More control captures cannot fix this. Byte 181 carries every 2^16 s, 18.2
hours; builds are about 160 s apart, so two consecutive controls straddle it
with probability about 0.24 percent and an expected single crossing needs on
the order of 410 consecutive control builds. Byte 180 carries every 2^24 s, 194
days. For any finite control set there is always a higher byte that did not
carry inside the window, and the spread required grows by 256 per byte. The
pull request that adds the tool says so, and says not to ask the build host for
more controls on this account.
Expected: the pin the tool already has for text, applied to a binary field. At
a run of differing offsets, read the enclosing fixed width big endian integer
and admit it only when all four hold:
- the controls' values at that field increase strictly in capture order;
- the unit's value exceeds every control's;
- the unit's step over the last control lies inside the range of the controls'
own steps, 158 to 172 in the run above;
- the field's lower bytes are among the offsets the controls vary at.
Every one of those is a measurement of the controls rather than an inference
about the unit, which is the standard the free region pin already meets, and it
is stricter than downgrading any monotone run, which was declined for being
inference. Under it the field above is noise legitimately, since 1790574596
beats 1790574436 by 160, and a planted value fails on the step range or on
failing to continue the sequence.
Not in #11 on purpose. That pull request adds the
instrument and publishes its first measurement honestly, 32 paths recorded as
an open item pointing here, and no waiver written over them, which the tool
refuses in any case because a waiver only ever clears overlapping. Landing a
new inference rule in the same change as the instrument, in order to make the
instrument's first subject pass, is how the defect that pull request exists to
fix came about.
bt-layer-measurepins a text difference by measuring the controls: at aposition they vary, the free region between their common prefix and suffix must
be one length, within a cap, and in the character class they used there. A
binary gets no such pin, because bytes carry no shape, so a coincidence in
position and magnitude is
overlappingand has to be cleared by hand.The mariadb gate run of 2026-09-28 shows what that costs. 32 of 167 differing
state paths come out
real, almost all*.MAI, and the reason is one field.Bytes 180 to 183 of an Aria index header, one based, are a four byte big endian
integer:
1790574106902134 / 10^6is1790574106, and that numerator isuser.frm'smicrosecond timestamp in the same directory, so the field is a wall clock
Unix second and
SOURCE_DATE_EPOCHdoes not touch it. It moves in everybuild, and the unit's value crossed into byte 181 where the three controls had
not, so it differs outside the floor.
More control captures cannot fix this. Byte 181 carries every 2^16 s, 18.2
hours; builds are about 160 s apart, so two consecutive controls straddle it
with probability about 0.24 percent and an expected single crossing needs on
the order of 410 consecutive control builds. Byte 180 carries every 2^24 s, 194
days. For any finite control set there is always a higher byte that did not
carry inside the window, and the spread required grows by 256 per byte. The
pull request that adds the tool says so, and says not to ask the build host for
more controls on this account.
Expected: the pin the tool already has for text, applied to a binary field. At
a run of differing offsets, read the enclosing fixed width big endian integer
and admit it only when all four hold:
own steps, 158 to 172 in the run above;
Every one of those is a measurement of the controls rather than an inference
about the unit, which is the standard the free region pin already meets, and it
is stricter than downgrading any monotone run, which was declined for being
inference. Under it the field above is
noiselegitimately, since 1790574596beats 1790574436 by 160, and a planted value fails on the step range or on
failing to continue the sequence.
Not in #11 on purpose. That pull request adds the
instrument and publishes its first measurement honestly, 32 paths recorded as
an open item pointing here, and no waiver written over them, which the tool
refuses in any case because a waiver only ever clears
overlapping. Landing anew inference rule in the same change as the instrument, in order to make the
instrument's first subject pass, is how the defect that pull request exists to
fix came about.