# [Known Issue] TiDB memory retention risk after client-go PriorityQueue change ([client-go#1834](https://github.com/tikv/client-go/issues/1834))

Source note: adapted from GitHub issue [client-go#1834](https://github.com/tikv/client-go/issues/1834) and related change [client-go#1095](https://github.com/tikv/client-go/pull/1095).

## Issue

- Link: [client-go#1834](https://github.com/tikv/client-go/issues/1834)
- Related change: [client-go#1095](https://github.com/tikv/client-go/pull/1095)
- Summary: after [client-go#1095](https://github.com/tikv/client-go/pull/1095) switched the batch request queue to a `PriorityQueue`, TiDB may show elevated memory usage that does not drop promptly after workload spikes. This is reported as a memory-retention issue and may look like a memory leak from the TiDB side.

## Phenomenon

- TiDB memory rises significantly during large transactions or bursty workloads.
- After the workload drops, memory usage stays much higher than the previous baseline for a long time instead of being released promptly.
- The issue is most visible in workloads that create many batch requests in client-go.

## Root Cause

The `PriorityQueue` implementation introduced by [client-go#1095](https://github.com/tikv/client-go/pull/1095) does not clear references in the slice backing array when items are removed, for example in `Pop()` and `Take(n >= Len)`.

Because those references remain in the backing array, Go GC cannot reclaim the removed objects promptly. The result is memory retention: objects that are no longer logically needed remain reachable from the queue's backing storage and keep memory pressure high.

## Trigger Condition

- TiDB version is `v8.0.0` or later.
- The workload creates many queued batch requests, for example:
  - high concurrency
  - large transactions
  - bursty request patterns that grow and then drain the queue
- The queue drains, but the backing array still retains object references.

## Diagnostic Steps

1. Confirm the TiDB version is `v8.0.0` or later.

1. Observe TiDB memory usage before, during, and after a workload spike. If memory remains high long after the spike ends, suspect memory retention in the batch request queue path.

1. Correlate the memory increase with workloads that generate many batch requests, such as large transactions or highly concurrent write/read bursts.

1. If deeper confirmation is needed, reproduce with the tests or analysis described in [client-go#1834](https://github.com/tikv/client-go/issues/1834) to verify backing-array retention in the `PriorityQueue`.

## Workaround

- Upgrade to a fixed version.
- If immediate mitigation is required and upgrading is not yet possible, restart the TiDB instance to release retained memory.

## Affected Version

- TiDB `v8.0.0+`

This is the first TiDB release line that depends on a client-go version containing [client-go#1095](https://github.com/tikv/client-go/pull/1095).

## Fixed Version

- v8.5.5

## Related Oncall

- v8.5.3 after insert finished, TiDB memory was not released TICKET-8201