Exercise 2: What "Idle in Transaction" Means, and Why It's a New Finding — Possible Solution
====================================================================

WHAT "IDLE IN TRANSACTION" MEANS
------------------------------
Per this chapter, connections were "stuck in PostgreSQL's own 'idle in
transaction' state, meaning a transaction was opened and never
committed or rolled back." The connection isn't actively running a
query at all - it's sitting idle, but still holding a transaction open
because the code that started that transaction never told the database
it was finished, one way or the other.

WHY THIS DIFFERS FROM CHAPTER 3's ORIGINAL SLOW-QUERY FINDING
------------------------------
Chapter 3's own original worked example found a single query still
actively running (in the 'active' state) for over four minutes - a
query genuinely taking a long time to execute. This ticket's
connections aren't running anything at all - they're idle, waiting
indefinitely because a transaction was never properly closed. Both
situations hold a connection hostage and exhaust the pool, but for
completely different reasons: one is a slow-executing query, the other
is a connection abandoned mid-transaction with no query running at all.

WHY THIS MATTERS FOR THE FIX
------------------------------
Per this chapter, the fix was to "wrap the transaction in a proper
try/finally so it's always closed regardless of how the request ends."
Optimizing a query (Chapter 3's original fix) would do nothing here,
since no query is actually slow - the fix has to address the code path
that opens a transaction but fails to guarantee it's closed under every
possible outcome, including an exception being thrown partway through.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines "idle in transaction" accurately, contrasts it specifically
against Chapter 3's original "active, long-running query" finding, and
explains why the two require genuinely different fixes despite both
producing pool exhaustion.