You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test(seekdb): stabilize intermittent migration DDL hang #1920
code-seekdb (3.14) intermittently times out in the migration stage while 3.11 passes. The code-indexing stage itself succeeds.
In this run, test_mysql_baseline_adoption_recovers_an_empty_committed_version_table[seekdb] hung on CREATE TABLE pc_schema_revision. Faulthandler triggered after 120 seconds, and the test was killed after 180 seconds. Native logs still showed an in-progress exclusive table lock.
The same test passes in other 3.14 runs in about 33 seconds, using the same pylibseekdb==1.4.0.post1. This appears to be a DDL or lifecycle race rather than deterministic Python 3.14 incompatibility.
Expected
Identify the seekDB lifecycle or lock condition, add bounded diagnostics, and keep repeated Python 3.11 and 3.14 runs stable without CI retries.
Root cause: When reopening a data directory, redo replay could reconstruct an undecided transaction and leave it marked for_replay. GC and timeout handling skip these replay-only contexts, so the transaction had no local completion driver after its original owner was gone. Its row or MDS table locks could consequently remain held indefinitely, blocking migration DDL such as CREATE TABLE pc_schema_revision.
Fix: After the replay barrier and local log-append activation, SeekDB now takes over recovered transactions before admitting new transactions:
Recovered INIT transactions and undecided MDS table-lock transactions go through the durable ABORT path, allowing normal transaction cleanup to release their locks.
Other recovered REDO_COMPLETE transactions continue through the existing commit-recovery protocol.
A completion timer is armed before leaving replay mode. Abort retries cover both MDS transaction-end preparation and abort-log submission, so temporary failures do not leave recovery stuck.
The PR reports passing crash-recovery regressions for uncommitted row redo and preservation of committed data. Retesting PowerContext should use a SeekDB/pylibseekdb build containing this change.
Activity
fix(tx): resolve replayed transactions before local write admission (#…
wangyunlai-seekdb commentedon Oct 16, 2026
Fixed by oceanbase/seekdb#1499, merged into SeekDB
masteron October 15.Root cause: When reopening a data directory, redo replay could reconstruct an undecided transaction and leave it marked
for_replay. GC and timeout handling skip these replay-only contexts, so the transaction had no local completion driver after its original owner was gone. Its row or MDS table locks could consequently remain held indefinitely, blocking migration DDL such asCREATE TABLE pc_schema_revision.Fix: After the replay barrier and local log-append activation, SeekDB now takes over recovered transactions before admitting new transactions:
INITtransactions and undecided MDS table-lock transactions go through the durableABORTpath, allowing normal transaction cleanup to release their locks.REDO_COMPLETEtransactions continue through the existing commit-recovery protocol.The PR reports passing crash-recovery regressions for uncommitted row redo and preservation of committed data. Retesting PowerContext should use a SeekDB/pylibseekdb build containing this change.
fix(tx): resolve replayed transactions before local write admission (…
PsiACE commentedon Nov 2, 2026
Resolved by #1945 and #2328, which adopt the patched SeekDB engine and pass native restart and recovery checks on Python 3.11 and 3.14.