1 million of district symbols limit

To reproduce

Review point M6 in https://github.com/questdb/java-questdb-client/pull/66#issuecomment-5183155169 is very valid

M6 — At the 1M cap, the error message's remedy is not performable through SenderPool (out-of-diff). getOrAddSymbol says "close this sender and build a new one", but PooledSender.close() (:153) gives the delegate back rather than closing it, and reset() does not clear globalSymbolDictionary. A delegate that hit the cap is handed to the next borrower still full, throwing on every new symbol value. Only incidental reapIdle recovers it.

QuestDB version:

latest

OS, in case of Docker specify Docker and the Host OS:

any

File System, in case of Docker specify Host File System:

any

Full Name:

Alex Pelagenko

Affiliation:

QuestDB

Have you followed Linux, MacOs kernel configuration steps to increase Maximum open files and Maximum virtual memory areas limit?

• Yes, I have

Additional context

No response

Read PooledSender.close() around line 153, then trace reset(), globalSymbolDictionary, and getOrAddSymbol through SenderPool. Reproduce the 1M-symbol-cap path and verify that a delegate borrowed after close/reset can accept new symbol values without relying on incidental reapIdle, while preserving the documented remedy.