pingcap/tidb · critical

Out Of Quota For Local Temporary Space!

Error message

Out Of Quota For Local Temporary Space!

What it means

Fired by globalPanicOnExceed in pkg/executor/select.go for the tracker labeled LabelForGlobalStorage: globalPanicStorageExceed is the constant 'Out Of Quota For Local Temporary Space!'. It is the disk-side counterpart of the memory panics: when the total data spilled to TiDB's temp storage across the server exceeds the configured quota, the action panics the query to stop temp-storage from filling the disk.

Source

Thrown at pkg/executor/select.go:182

}

// Action panics when storage usage exceeds storage quota.
func (a *globalPanicOnExceed) Action(t *memory.Tracker) {
	a.mutex.Lock()
	defer a.mutex.Unlock()
	msg := ""
	switch t.Label() {
	case memory.LabelForGlobalStorage:
		msg = globalPanicStorageExceed
	case memory.LabelForGlobalMemory:
		msg = globalPanicMemoryExceed
	case memory.LabelForGlobalAnalyzeMemory:
		msg = globalPanicAnalyzeMemoryExceed
	default:
		msg = "Out of Unknown Resource Quota!"
	}
	// TODO(hawkingrei): should return error instead.
	panic(msg)
}

// GetPriority get the priority of the Action
func (*globalPanicOnExceed) GetPriority() int64 {
	return memory.DefPanicPriority
}

// SelectLockExec represents a select lock executor.
// It is built from the "SELECT .. FOR UPDATE" or the "SELECT .. LOCK IN SHARE MODE" statement.
// For "SELECT .. FOR UPDATE" statement, it locks every row key from source Executor.
// After the execution, the keys are buffered in transaction, and will be sent to KV
// when doing commit. If there is any key already locked by another transaction,
// the transaction will rollback and retry.
type SelectLockExec struct {
	exec.BaseExecutor

	Lock *ast.SelectLockInfo
	keys []kv.Key

View on GitHub (pinned to d01f9615c1)

Solutions

  1. Free temp-storage pressure: wait for/kill spilled queries, then raise the quota (temp-storage-quota / tidb_global_storage_quota) or point tmp-storage-path at a bigger disk.
  2. Reduce spill volume at the source: filter/project before sort/join, add indexes, split the query, or raise the per-query memory quota so it stops spilling.
  3. Throttle concurrency of large queries (resource control / max_connections) so total spill stays under quota.
  4. Check the disk backing tmp-storage-path for free space and stale spill files after crashes.

Example fix

# before: small temp quota + heavy spill
# config: temp-storage-quota = 1GB, query spills 5GB -> panic

# after: give spill room and bound concurrency
# config.toml
[temp-storage]
path = "/data/tidb-temp"
# quota MB (0 = use 80% of disk)
Defensive patterns

Strategy: validation

Validate before calling

-- monitor temp storage usage before/while running spill-heavy queries
SELECT * FROM information_schema.instance_memory_usage WHERE item LIKE '%disk%';
-- and check the disk backing temp-storage-path
SELECT file_name, total_pages*16/1024 AS mb FROM information_schema.disk_usage LIMIT 5; -- generic disk check via OS preferred

Try / catch

-- the panic surfaces as error 1105 on the spilled query;
-- catch client-side, reduce the query or wait for other spills to drain, then retry

Prevention

When it happens

Trigger: Operators spilling to temp storage (Sort/Join/Agg spills, spilled result, chunk-in-disk buffers, temp tables) whose combined on-disk bytes exceed the global storage quota (temp-storage-quota / tidb_global_storage_quota) - e.g. several concurrent large sort spills, or a cursor/server result set buffered in disk by rows.

Common situations: Memory quota lowered so big queries spill heavily; many concurrent large analytical queries all spilling at once; tmp-storage-path on a small disk with quota set close to capacity; the cursor test scenario in the repo (pkg/server/tests/cursor) where server-side result sets spill to temp storage.

Related errors

AI-assisted analysis of pingcap/tidb@d01f9615c1 (2026-08-15). Data as JSON: /api/errors/4d415e11b08134a3. Report an issue: GitHub.