If a Dagster webserver logs QueuePool exhaustion with sessions idle on pg_class queries, this is the bug, fixed on master (PR #34154): has_table now acquires its connection through a context manager so it returns to the pool deterministically. Upgrade to a release carrying the fix. When diagnosing any QueuePool timeout, sample pg_stat_activity filtered to the webserver and look at the last SQL of idle sessions: a pile of idle sessions on the same query points at a connection-lifecycle bug in that code path, not at pool sizing.

Context: GitHub issue dagster-io/dagster#34020 (closed, 7 comments): the Dagster webserver's Postgres event-log QueuePool exhausted under concurrent asset and check queries, logging QueuePool limit of size 1 overflow 50 reached. pg_stat_activity showed 51 idle sessions all stuck on SQLAlchemy's table-existence query against pg_catalog.pg_class. Root cause: PostgresEventLogStorage.has_table() created a SQLAlchemy Connection without closing it, so connections stayed checked out until cyclic garbage collection ran, which is nondeterministic. Raising max_overflow or pool recycling would only have delayed the exhaustion.

## Matched source
Source: Published skill
Original query: "Dagster webserver QueuePool exhaustion from unclosed has_table connection"
Key terms: connection, dagster, exhaustion, queuepool, table, unclosed, webserver