{"record":{"id":"4d415e11b08134a3","repo":"pingcap/tidb","slug":"out-of-quota-for-local-temporary-space","errorCode":null,"errorMessage":"Out Of Quota For Local Temporary Space!","messagePattern":"Out Of Quota For Local Temporary Space!","errorType":"panic","errorClass":null,"httpStatus":null,"severity":"critical","filePath":"pkg/executor/select.go","lineNumber":182,"sourceCode":"}\n\n// Action panics when storage usage exceeds storage quota.\nfunc (a *globalPanicOnExceed) Action(t *memory.Tracker) {\n\ta.mutex.Lock()\n\tdefer a.mutex.Unlock()\n\tmsg := \"\"\n\tswitch t.Label() {\n\tcase memory.LabelForGlobalStorage:\n\t\tmsg = globalPanicStorageExceed\n\tcase memory.LabelForGlobalMemory:\n\t\tmsg = globalPanicMemoryExceed\n\tcase memory.LabelForGlobalAnalyzeMemory:\n\t\tmsg = globalPanicAnalyzeMemoryExceed\n\tdefault:\n\t\tmsg = \"Out of Unknown Resource Quota!\"\n\t}\n\t// TODO(hawkingrei): should return error instead.\n\tpanic(msg)\n}\n\n// GetPriority get the priority of the Action\nfunc (*globalPanicOnExceed) GetPriority() int64 {\n\treturn memory.DefPanicPriority\n}\n\n// SelectLockExec represents a select lock executor.\n// It is built from the \"SELECT .. FOR UPDATE\" or the \"SELECT .. LOCK IN SHARE MODE\" statement.\n// For \"SELECT .. FOR UPDATE\" statement, it locks every row key from source Executor.\n// After the execution, the keys are buffered in transaction, and will be sent to KV\n// when doing commit. If there is any key already locked by another transaction,\n// the transaction will rollback and retry.\ntype SelectLockExec struct {\n\texec.BaseExecutor\n\n\tLock *ast.SelectLockInfo\n\tkeys []kv.Key","sourceCodeStart":164,"sourceCodeEnd":200,"githubUrl":"https://github.com/pingcap/tidb/blob/d01f9615c13e02dfa75922745640dec9d81b802e/pkg/executor/select.go#L164-L200","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","solutions":["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.","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.","Throttle concurrency of large queries (resource control / max_connections) so total spill stays under quota.","Check the disk backing tmp-storage-path for free space and stale spill files after crashes."],"exampleFix":"# before: small temp quota + heavy spill\n# config: temp-storage-quota = 1GB, query spills 5GB -> panic\n\n# after: give spill room and bound concurrency\n# config.toml\n[temp-storage]\npath = \"/data/tidb-temp\"\n# quota MB (0 = use 80% of disk)\n","handlingStrategy":"validation","validationCode":"-- monitor temp storage usage before/while running spill-heavy queries\nSELECT * FROM information_schema.instance_memory_usage WHERE item LIKE '%disk%';\n-- and check the disk backing temp-storage-path\nSELECT file_name, total_pages*16/1024 AS mb FROM information_schema.disk_usage LIMIT 5; -- generic disk check via OS preferred","typeGuard":null,"tryCatchPattern":"-- the panic surfaces as error 1105 on the spilled query;\n-- catch client-side, reduce the query or wait for other spills to drain, then retry","preventionTips":["Give tmp-storage-path a dedicated, large volume and set temp-storage-quota accordingly.","Bound concurrency of large sorts/joins with resource groups so total spill stays under quota.","Alert on temp-dir free space, not just memory usage."],"tags":["tidb","temp-storage","spill","disk-quota","panic"],"backgroundTag":null,"analyzedSha":"d01f9615c13e02dfa75922745640dec9d81b802e","analyzedAt":"2026-08-15T12:19:33.324Z","schemaVersion":2},"datasetVersion":"2026-08-15T22:17:37.221Z"}