$32 = {txnid = 2064, durable_ts = 6963901763766190115, start_ts = 6963901763766190115, prev_durable_ts = 0, next = 0x7fa415c34220, size = 1023, type = 3 '\003',
prepare_state = 0 '\000', flags = 1 '\001', data = 0x7fa41533c6cf "\377\003"}
(gdb) p *$27->next->next->next->next->next->next
$33 = {txnid = 2064, durable_ts = 6963901763766190115, start_ts = 6963901763766190115, prev_durable_ts = 0, next = 0x7fa43b7a3020, size = 1023, type = 3 '\003',
prepare_state = 0 '\000', flags = 0 '\000', data = 0x7fa415c3424f "\377\003"}
(gdb) p *$27->next->next->next->next->next->next->next
$34 = {txnid = 2064, durable_ts = 6963901763766190111, start_ts = 6963901763766190111, prev_durable_ts = 0, next = 0x7fa414be74a0, size = 1023, type = 3 '\003',
prepare_state = 0 '\000', flags = 0 '\000', data = 0x7fa43b7a304f "\377\003"}
(gdb) p *$27->next->next->next->next->next->next->next->next
$35 = {txnid = 2064, durable_ts = 6963901763766190115, start_ts = 6963901763766190115, prev_durable_ts = 0, next = 0x7fa41480cb20, size = 1023, type = 3 '\003',
prepare_state = 0 '\000', flags = 0 '\000', data = 0x7fa414be74cf "\377\003"}
(gdb) p *$27->next->next->next->next->next->next->next->next->next
$36 = {txnid = 2064, durable_ts = 6963901763766190113, start_ts = 6963901763766190113, prev_durable_ts = 0, next = 0x7fa415135220, size = 1023, type = 3 '\003',
prepare_state = 0 '\000', flags = 4 '\004', data = 0x7fa41480cb4f "\377\003"}
In this case, we have an out of order update at $35 and its older update $36 has the same transaction id and timestamp as $32, which is the value chosen to be written to the new disk image. Therefore, all these updates including the out of order timestamp is squashed, which is wrong.
- related to
-
SERVER-57174 Tightening timestamp order within a single transaction
-
- Closed
-