Spec §6.3's environment rules: pooled-connection detection and the advisory lock. classify_config/1 is pure (the config-based half of mix phoenix_kit.doctor's existing PgBouncer heuristic, doctor.ex:174-195, reused rather than re-derived); pooled?/1 and the lock functions execute real queries and have no unit test.

Detection is two-layered, on purpose

Config alone (a non-5432 port, a hostname containing "pgbouncer") is a fast, always-available hint — it is what mix phoenix_kit.doctor already prints a warning from. It is not proof: a direct Postgres connection can legitimately run on a non-standard port, and a transaction-pooling proxy can sit behind a hostname that says nothing about it. The authoritative signal is behavioral: pg_backend_pid() sampled twice over the SAME checked-out connection, as two separate (non-transactional) statements. A direct connection — or a session-pooling proxy, which behaves like one for this purpose — answers with the same pid both times, because both statements ride the one physical server backend for as long as the connection is checked out. Transaction-pooling PgBouncer can hand each statement a different backend connection, because nothing binds them together outside an explicit transaction. pooled?/1 therefore checks out one connection (Ecto.Repo.checkout/2) before sampling — sampling via two plain repo.query!/3 calls without checking out first would let Ecto's own pool (nothing to do with PgBouncer) hand the two queries to different workers and manufacture a false positive on a perfectly direct database.

Config classification and pid-sampling are combined with OR: either one saying "pooled" is enough to require --unsafe-pooled — false positives (an operator has to pass one extra flag) are the safe failure direction; false negatives (skipping VALIDATE/the advisory lock against a pooled connection that fooled both checks) are not.