fix(db): keep the DSN's application_name across pool reuse (blank pg_stat_activity behind pgbouncer)

[nicoloboschi]

Problem

A DSN like

postgresql://user:pass@host:5432/db?application_name=my-worker

labels the session correctly under psql, and correctly on the service's first connection — then reports an empty application_name in pg_stat_activity for the rest of the process's life once a connection pooler sits in front of PostgreSQL. Everything keyed on the session name loses attribution: pg_stat_activity, operator dashboards, the [DB_WAITS] diagnostics in worker/poller.py that print app=, and any SQL reading current_setting('application_name'). No error — just blank names, and only in the deployed topology.

Root cause

Not a DSN-parsing gap: asyncpg does forward the DSN's application_name in the startup packet (it passes unrecognized DSN query parameters through as server_settings). The loss happens on connection reuse.

asyncpg's pool runs RESET ALL when a connection is released (Connection.get_reset_query). Direct to PostgreSQL that is harmless — RESET ALL restores the value from the startup packet, which carried the name. Behind pgbouncer it is not: the server connection's startup packet is the pooler's own and has no application_name; pgbouncer applies the client's value with a SET when it links client to server. RESET ALL therefore clears it to empty, and pgbouncer — which already believes the value is applied — never re-issues it. Only the first acquire on each server connection is attributed.

Fix

Re-assert the name from the pool's setup hook, which asyncpg runs on every acquire, after the release-time RESET ALL. This is the same mechanism the backend already relies on to keep hnsw.ef_search and the other session GUCs applied across connection reuse (the init=/setup= pair right below it). set_config() rather than SET because the name is operator-supplied and SET does not accept bind parameters.

DSNs without the parameter are untouched — the caller's init_callback is passed through unwrapped, so there is no extra statement per acquire.

Verification

Against pgbouncer 1.25.1 → PostgreSQL 16, reading the real backend's name out of pg_stat_activity:

	acquire #1	#2	#3
before	hs-worker-7	''	''
after	hs-worker-7	hs-worker-7	hs-worker-7

Also verified: unchanged on a direct connection; unchanged when the DSN carries no application_name; the caller's init_callback still runs on every acquire; and under session pooling with 5 concurrent clients × 6 acquires across 6 server connections, 0/30 mis-attributed — with a name containing a single quote, confirming the bind parameter is injection-safe.

Note on transaction pooling: session-scoped state is inherently not guaranteed to reach the backend serving the next statement, so residual mis-attribution is possible there. That applies equally to the session GUCs this backend already sets (hnsw.ef_search, statement_timeout, pg_trgm.similarity_threshold) and is out of scope here.

Tests

tests/test_dsn_application_name.py — deterministic, no DB (asyncpg.create_pool monkeypatched to capture the hooks):

• parser: present / absent / other-params / repeated parameter (libpq last-wins) / empty value / unparseable DSN
• the setup hook issues set_config('application_name', $1, false) and re-applies it on a second acquire
• the wrapper still invokes the caller's init_callback (session GUCs must not be displaced)
• no application_name in the DSN → the callback is passed through unwrapped; no callback either → hooks stay None