planner: activate stale-read txn when autocommit=0 #65908

wfxr · 2026-01-29T08:16:24Z

What problem does this PR solve?

Issue Number: close #64198

Problem Summary:

When autocommit=0 and tidb_read_staleness is set, each SELECT statement recalculates its own read_ts instead of reusing the same snapshot. This causes inconsistent reads across multiple statements within what users expect to be a single transaction.

What changed and how does it work?

Changed EnterNewTxnWithReplaceProvider to EnterNewTxnWithBeginStmt when !IsAutocommit() in updateStateFromStaleReadProcessor(). This triggers activateStaleTxn() in StalenessTxnContextProvider.This ensures:

InTxn() becomes true after the first SELECT
Subsequent reads reuse the same snapshot (StartTS)
Write statements are rejected (existing behavior)
COMMIT/ROLLBACK ends the transaction normally

Check List

Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No need to test
- I checked and no code files have been changed.

Side effects

Performance regression: Consumes more CPU
Performance regression: Consumes more Memory
Breaking backward compatibility

Documentation

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Fix an issue that stale read with `tidb_read_staleness` does not provide consistent snapshot when `autocommit=0`, causing each SELECT to use a different `read_ts` instead of reusing the same snapshot within the transaction.

ti-chi-bot · 2026-01-29T08:16:27Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

tiprow · 2026-01-29T08:16:33Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

wfxr · 2026-01-29T08:25:35Z

/test all

wfxr · 2026-01-29T09:56:00Z

/retest

wfxr · 2026-01-29T11:06:36Z

/test all

codecov · 2026-01-29T11:33:08Z

Codecov Report

❌ Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.4591%. Comparing base (060097f) to head (897af91).
⚠️ Report is 38 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #65908        +/-   ##
================================================
- Coverage   77.7756%   77.4591%   -0.3166%     
================================================
  Files          2001       1923        -78     
  Lines        545524     538914      -6610     
================================================
- Hits         424285     417438      -6847     
- Misses       119577     121461      +1884     
+ Partials       1662         15      -1647

Flag	Coverage Δ
integration	`41.4981% <57.1428%> (-6.6667%)`	⬇️
unit	`76.7096% <71.4285%> (+0.2969%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	`56.7974% <ø> (ø)`
parser	`∅ <ø> (∅)`
br	`48.4687% <ø> (-12.5171%)`	⬇️

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

wfxr · 2026-01-29T12:46:51Z

/test all

wfxr · 2026-01-29T14:50:13Z

/retest

wfxr · 2026-01-30T01:54:15Z

/retest

wfxr · 2026-01-30T05:26:11Z

/retest

When `autocommit=0` and stale read is enabled, the first SELECT now activates a proper stale-read transaction instead of just replacing the provider. This ensures: 1. `InTxn()` becomes true after the first SELECT 2. Subsequent reads reuse the same snapshot (StartTS) 3. Write statements are rejected (existing behavior) 4. COMMIT/ROLLBACK ends the transaction normally

cfzjywxk · 2026-02-02T09:30:47Z

pkg/sessiontxn/txn_context_test.go

+	tk.MustExec("create table t (id int primary key, v int)")
+	tk.MustExec("insert into t values (1, 10)")
+
+	time.Sleep(2 * time.Second)


Is it possible to use mock/injected ts allocator or failpoint so the Sleep here could be avoided?

Sleeping in CI test case may slow down CI processing.

I tried rewriting this using a mock or failpoint to eliminate the Sleep, but neither approach worked out.

I also looked at other similar tests, and they seem also rely on a sleep to ensure stale read returns the expected data (please let me know if I missed a better pattern).

As a small improvement, we could shorten the sleep to 1.2s; it passes reliably in repeated runs on my machine. Would you be OK with this change?

cfzjywxk · 2026-02-02T09:41:14Z

pkg/sessiontxn/txn_context_test.go

 	require.Equal(t, uint64(99), count)
 }
+
+func TestStaleReadTxnWithAutocommitOff(t *testing.T) {


We need to also cover the plan cache path(so is the prepared statement) as key information of stale read is processed during planning statge.

Former critical issue encounterred #54652.

Added test cases for this.

cfzjywxk · 2026-02-02T09:41:36Z

pkg/sessiontxn/txn_context_test.go

+	tk.MustExec("create table t2 (id int)")
+	require.False(t, sessVars.InTxn(), "DDL should implicitly end the stale-read txn")
+	tk.MustExec("drop table t2")
+}


Should select as of timestamp be verified here too?

Currently, using select as of timestamp together with autocommit = 0 yields uncertain results.

According to the Stale Read Product Design, SELECT ... AS OF TIMESTAMP

Can not be used together with other Stale Read features or variables.

If the variable tidb_read_staleness is set at the same time, it will be ignored and the tso in SELECT ... AS OF TIMESTAMP will take effect.

If the variable tidb_external_ts is set at the same time,

Only used in the implicit transaction with autocommit = 1.
Statement level stale read can not be used in an explicit transaction. Otherwise, there may be different staleness in one transaction.

There is a separate pr #65960 to resolve this, making the behavior conform to the intended design.

lcwangchao · 2026-02-02T11:26:13Z

pkg/planner/core/preprocess.go

+				enterType := sessiontxn.EnterNewTxnWithReplaceProvider
+				if !p.sctx.GetSessionVars().IsAutocommit() {
+					// start a stale-read transaction so that subsequent reads reuse the same snapshot.
+					enterType = sessiontxn.EnterNewTxnWithBeginStmt


EnterNewTxnWithBeginStmt seems only be used by by begin / start tarnsaction only. How about still to use EnterNewTxnWithReplaceProvider and check the IsAutocommit in EnterNewTxnWithReplaceProvider:: enterNewStaleTxnWithReplaceProvider and if IsAutocommit returns true, you can call activateStaleTxn.

tidb/pkg/sessiontxn/staleread/provider.go

Lines 78 to 88 in bbeaafd

func (p *StalenessTxnContextProvider) OnInitialize(ctx context.Context, tp sessiontxn.EnterNewTxnType) error {

p.ctx = ctx

switch tp {

case sessiontxn.EnterNewTxnDefault, sessiontxn.EnterNewTxnWithBeginStmt:

return p.activateStaleTxn()

case sessiontxn.EnterNewTxnWithReplaceProvider:

return p.enterNewStaleTxnWithReplaceProvider()

default:

return errors.Errorf("Unsupported type: %v", tp)

}

}

tidb/pkg/sessiontxn/staleread/provider.go

Lines 141 to 155 in bbeaafd

func (p *StalenessTxnContextProvider) enterNewStaleTxnWithReplaceProvider() error {

if p.is == nil {

is, err := GetSessionSnapshotInfoSchema(p.sctx, p.ts)

if err != nil {

return err

}

p.is = is

}

txnCtx := p.sctx.GetSessionVars().TxnCtx

txnCtx.TxnScope = kv.GlobalTxnScope

txnCtx.IsStaleness = true

txnCtx.InfoSchema = p.is

return nil

}

Oh, maybe we should call ActivateTxn and call SetInTxn(true) in GetStmtReadTS if autocommit=0 to keep the autocommit behavior consistency with normal.

And seems there is bug (not introduced by this PR):

> start transaction read only as of timestamp now()- interval 1 second; > select * from information_schema.tables limit 1; -- the transaction will be closed after this statement

Oh, maybe we should call ActivateTxn and call SetInTxn(true) in GetStmtReadTS if autocommit=0 to keep the autocommit behavior consistency with normal.

👍 Good suggestion! This approach is indeed more elegant, and I've verified that it works.

I have one question: I noticed another method, GetSnapshotWithStmtReadTS, which is similar to GetStmtReadTS. However, it seems to be used only in PointGet / BatchPointGet during the execution phase and some tests. I assume we don't need to apply the same handling there, right?

select * from information_schema.tables limit 1;

@lcwangchao I can confirm the bug. Considering the current PR's scope, would you prefer me to open a new issue to document this?

wfxr · 2026-02-03T12:34:56Z

/retest

ti-chi-bot · 2026-02-04T02:29:21Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign qiuyesuifeng for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

wfxr · 2026-02-04T03:14:14Z

/retest

ti-chi-bot bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. sig/planner SIG: Planner labels Jan 29, 2026

ti-chi-bot bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 29, 2026

wfxr force-pushed the stale-read/64198 branch 3 times, most recently from 2857898 to da39e55 Compare January 29, 2026 08:21

wfxr force-pushed the stale-read/64198 branch from da39e55 to ea4473c Compare January 29, 2026 10:13

wfxr force-pushed the stale-read/64198 branch from ea4473c to a487a74 Compare January 29, 2026 12:46

wfxr marked this pull request as ready for review January 30, 2026 03:05

ti-chi-bot bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 30, 2026

wfxr force-pushed the stale-read/64198 branch from a487a74 to 3fa273c Compare January 30, 2026 06:17

cfzjywxk requested review from cfzjywxk, lcwangchao and qw4990 February 2, 2026 09:03

cfzjywxk reviewed Feb 2, 2026

View reviewed changes

cfzjywxk added the sig/transaction SIG:Transaction label Feb 2, 2026

lcwangchao reviewed Feb 2, 2026

View reviewed changes

review: add prepared statement test cases

dc2c98e

review: shorten sleep time in test

361c254

review: better way to active the txn

897af91

	func (p *StalenessTxnContextProvider) OnInitialize(ctx context.Context, tp sessiontxn.EnterNewTxnType) error {
	p.ctx = ctx
	switch tp {
	case sessiontxn.EnterNewTxnDefault, sessiontxn.EnterNewTxnWithBeginStmt:
	return p.activateStaleTxn()
	case sessiontxn.EnterNewTxnWithReplaceProvider:
	return p.enterNewStaleTxnWithReplaceProvider()
	default:
	return errors.Errorf("Unsupported type: %v", tp)
	}
	}

	func (p *StalenessTxnContextProvider) enterNewStaleTxnWithReplaceProvider() error {
	if p.is == nil {
	is, err := GetSessionSnapshotInfoSchema(p.sctx, p.ts)
	if err != nil {
	return err
	}
	p.is = is
	}

	txnCtx := p.sctx.GetSessionVars().TxnCtx
	txnCtx.TxnScope = kv.GlobalTxnScope
	txnCtx.IsStaleness = true
	txnCtx.InfoSchema = p.is
	return nil
	}

planner: activate stale-read txn when autocommit=0 #65908

Are you sure you want to change the base?

planner: activate stale-read txn when autocommit=0 #65908

Conversation

wfxr commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What problem does this PR solve?

What changed and how does it work?

Check List

Release note

Uh oh!

ti-chi-bot bot commented Jan 29, 2026

Uh oh!

tiprow bot commented Jan 29, 2026

Uh oh!

wfxr commented Jan 29, 2026

Uh oh!

wfxr commented Jan 29, 2026

Uh oh!

wfxr commented Jan 29, 2026

Uh oh!

codecov bot commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

wfxr commented Jan 29, 2026

Uh oh!

wfxr commented Jan 29, 2026

Uh oh!

wfxr commented Jan 30, 2026

Uh oh!

wfxr commented Jan 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcwangchao Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wfxr commented Feb 3, 2026

Uh oh!

ti-chi-bot bot commented Feb 4, 2026

Uh oh!

wfxr commented Feb 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

wfxr commented Jan 29, 2026 •

edited

Loading

codecov bot commented Jan 29, 2026 •

edited

Loading

lcwangchao Feb 2, 2026 •

edited

Loading