You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Commit 5ab014a
Browse filesBrowse the repository at this point in the historyBrowse files
Share fixture workers through the launcher in tests; add launch: worker strings
Client(server_path) now accepts the DuckDB extension's launch:<argv> scheme,
selecting transport="launch" with the argv split shlex-style, so one worker
string names the same shared worker in both clients.
The test suite uses it to reach its fixture workers by default: every
fixture-worker Client goes through vgi_rpc.launcher, one warm worker per
command shared by every xdist process, instead of each process growing its own
pool (and subprocess-direct spawning a worker per test). At -n 32 on a 48-core
box that was hundreds of live vgi-fixture-worker processes.
- VGI_TEST_CLIENT_TRANSPORT=subprocess restores the per-process pools (the
default on Windows, which has no AF_UNIX); the client_transport matrix runs
launch + http, or the subprocess legs under that setting.
- A per-session VGI_RPC_TEST_SESSION lands in the launcher's hash domain, so a
session never reuses a warm worker from an earlier run of older code; the
controller stops the session's workers at unconfigure.
- The shared worker runs with --max-connections 0: at 64, scans holding
connections while their next one waits in the backlog can deadlock.
- Tests of the subprocess transport itself (stderr capture, force-stop, worker
debug) and the catalog DDL suite (fresh InMemoryCatalog per test) stay on
subprocess; test_subprocess_transport.py keeps pooled and direct covered.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments