Transactions that allocate blocks to commit their updates no longer encounter TPFAIL errors with a failure code of eeee
Final Release Note
Transactions that allocate blocks to commit their updates no longer encounter TPFAIL errors with a failure code of eeee when the total number of blocks allocated since opening the database file exceeds 2**31. Previously, they did. The workaround was to monitor $$^%PEEKBYNAME("node_local.tp_hint",reg) and to shutdown all processes accessing that database file and then to restart the processes. MUPIP RUNDOWN can be used to verify that there are no processes accessing a database file. [#944 (closed)]
Description
This is an issue that was reported by a user. node_local.tp_hint
is a 32-bit block hint counter that is used by transactions when allocating created blocks inside a TSTART/TCOMMIT fence. This is a signed
value. And gets incremented as each transaction that allocated a block commits. So if lots of TSTART/TCOMMIT transactions create (and possibly kill) blocks, this counter could eventually reach a value of 2**31
. Once it reaches that value, this counter gets interpreted as a negative number due to the signed
nature of the underlying data type. And that causes code that operates on this hint to get confused and issue a TPFAIL error with a failure code e
.
And from then on, any update inside TSTART/TCOMMIT that tries to create blocks will end up with a TPFAIL error. Updates outside of TSTART/TCOMMIT will be fine. Database will be fine too. But TSTART/TCOMMIT updates will issue TPFAIL errors until this counter is fixed (one way to fix it would be to shutdown the database and restart it).
This is an issue that YottaDB inherited from the upstream (GT.M). It has been there since V6.3-001 and exists till GT.M V6.3-014. This is automatically fixed in V7.0-000 because the block_id
type (which is the underlying type for the node_local.tp_hint
counter) became an 8-byte quantity in that release. And so, node_local.tp_hint
automatically became an 8-byte SIGNED number and it is imposible to overflow this number (i.e. go more than 2**63) in practice.
YottaDB master branch has this issue since GT.M V7.0-000 has not yet been merged. Since r1.36 will not have GT.M V7.0-000 merged, this issue is being created so we fix this counter overflow issue.