fix(logtail): stream-publish txn tails to remove batch-wide wait (#24325)

[ck89119]

What type of PR is this?

• BUG
• API-change
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #24325

What this PR does / why we need it:

Background

PR #22475 refactored Manager.onTxnLogTails in
pkg/vm/engine/tae/logtail/mgr.go so that a batch of txns are
collected in parallel and then published after a batch-wide
collectWg.Wait():

for i, item := range items {
    mgr.collectWg.Add(1)
    mgr.collectPool.Submit(func() {
        defer mgr.collectWg.Done()
        txn.GetStore().WaitEvent(txnif.WalPreparing)
        ...
        state := txn.GetTxnState(true)
        mgr.orderedList[i] = txnTail
    })
}
mgr.collectWg.Wait()                 // ← blocks on slowest txn
for i := range items {
    mgr.generateLogtailWithTxn(...)  // serial push AFTER all ready
}

Batch size is 100. Under high-concurrency short-tx workloads (e.g.
sysbench oltp_delete t=32), the batch regularly fills up and a single
slow txn defers logtail publish for all others. CN observes this
through txnOperator.unlock → timestampWaiter.GetTimestamp waiting on
NotifyLatestCommitTS, which in RC isolation gates commit return,
inflating per-txn latency.

This causes issue #24325: sysbench oltp_delete t=32 standalone TPS
drops ~28% at the exact commit that merged #22475, and ~17% on main
HEAD vs 3.0-dev (which does not carry #22475).

Fix

Replace the batch-wide wait with per-slot buffered channels + a serial
publisher that reads slot 0, 1, 2, ... in order:

• each submit goroutine signals its own chan *txnWithLogtails on completion
• the publisher loops through slots in index order, <-ch per slot
• a slow txn only blocks the publisher up to its slot; it does not
  delay the collection of later txns nor the publishing of earlier
  already-ready txns

All other #22475 changes (single logtailQueue, collectPool,
WaitEvent(WalPreparing) event) are preserved.

Monotonicity of previousSaveTS inside generateLogtailWithTxn is
preserved since publish still happens in index (PrepareTS) order.

Benchmark

sysbench oltp_delete.lua on standalone MO, Apple Silicon arm64,
GOMAXPROCS=10, 10 tables × 1M rows, threads=32, time=60s,
db-ps-mode=disable, skip_trx=on, 3 independent runs (fresh prepare +
cleanup + mo-service restart per run), mean of 30-60s steady window:

Version	Steady TPS	timestampWaiter per-txn
main before this PR	7970	585 μs
main + this fix	9402	334 μs
3.0-dev (no #22475)	9326	127 μs
8b3700a (commit before #22475)	10487	123 μs

TPS recovers +17.9% over current main and passes 3.0-dev. The
remaining tw gap vs 3.0-dev (334 μs → 127 μs) is secondary and does
not materially affect TPS at t=32; it can be pursued separately if
needed.

Ablation (confirming the hotspot is exactly this function)

Each candidate fix applied in isolation on main HEAD, 3-run mean:

Candidate fix	Steady TPS	tw per-txn
main baseline	7970	585 μs
parallelize LogEntryWriter.Finish() marshal	8283	592 μs
synchronous marshal in cmdmgr.ApplyTxnRecord	8280	599 μs
this PR (stream-publish in onTxnLogTails)	9402	334 μs

Only touching onTxnLogTails produces the recovery; marshal-path
rewrites do not, which rules out marshal deferral itself as the
regression source.

[qodo-code-review]

ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one.