pdo_pgsql_pool_killed_concurrent

[EdmondDantes]

Summary

Test tests/pdo_pgsql/029-pdo_pgsql_pool_killed_concurrent.phpt периодически падает на CI с диффом:

```

• Pool count: 1

• Pool count: 2
  Done
  ```

После `pg_terminate_backend` ожидается, что pool count упадёт с 2 до 1 в течение polling-окна, но иногда счётчик остаётся 2.

Latest occurrence

• Branch: `108-channel0-send-returns-without-a-waiting-receiver`
• Run ID: 25634890334 (True Async Ubuntu Speed Test)
• Date: 2026-05-10
• URL: https://github.com/true-async/php-async/actions/runs/25634890334
• Time: `5.803s` slow tag
• Commit under test: `e29e036` (Channel0 send returns without a waiting receiver #108 Channel(0) rendezvous fix — unrelated to pgsql)

Prior history of the same test

• `686a6ab` Add PDO pool broken connection tests
• `f97dca9` Fix flaky kill-concurrent tests: increase sleep to 30s
• `e93c679` Fix flaky kill-concurrent tests
• `413174a` tests: remove order-dependence from two flaky tests
• `be6531f` libuv reactor: getaddrinfo result leaks when consumer is cancelled before disposal #111: extend pool-count polling window to 5s
• `e4d9a59` Revert "libuv reactor: getaddrinfo result leaks when consumer is cancelled before disposal #111: extend polling window to 5s"
• `5161366` trigger CI: pick up pdo_pgsql conn_broken fix from true-async-stable

The polling-window extension was tried and reverted, so the underlying race is not "polling too short" — there is something else going on.

Hypothesis

After `pg_terminate_backend(pid)`:

• libpq on the killed connection's next syscall must observe `SSL_read` / `recv` failure and the pool's broken-connection detector must mark the slot as broken and decrement count.
• If the killed coroutine is parked in a different state (e.g., not actively reading, or the next event loop tick hasn't yet processed the terminated socket), `pool->count()` reports the stale value.

Possibly the broken-connection callback isn't wired to fire when the connection is idle in the pool (only when actively doing IO), so until somebody tries to use that slot, it isn't released.

Repro

```bash
cd ext/async
for i in {1..30}; do
/usr/local/bin/php-cgi ../../run-tests.php -P -q -j4
tests/pdo_pgsql/029-pdo_pgsql_pool_killed_concurrent.phpt 2>&1
| grep -E "PASS|FAIL"
done
```

Suggested next steps

1. Reproduce locally under load (the failure surfaces on CI runners more often than on dev boxes — possibly CPU-starved scheduling).
2. Inspect what triggers the slot release: is it the broken-connection callback firing on the libpq fd, or a polling check?
3. If callback-driven: ensure the callback is registered while the slot is idle, not only while a coroutine holds it.
4. If polling: investigate whether 5s window from `libuv reactor: getaddrinfo result leaks when consumer is cancelled before disposal #111` was actually enough (the revert may have been premature).

[EdmondDantes]

Fixed in #115 (merged):

• pdo_pgsql C-код: detect broken on sqlstate==NULL && PGRES_FATAL_ERROR; new pdo_pgsql_pool_before_acquire runs non-blocking PQconsumeInput+PQstatus so killed-but-idle slots are evicted on next acquire.
• Test 029 polling loop now drives a probing SELECT 1 so the scrub fires before pool->count() is sampled.
• Bonus: pdo_mysql/010 Threads_connected-based leak check replaced with process-local PROCESSLIST poll (was false-failing under -jN parallel workers).

Local repro: 0/250 FAILs after fix (vs ~5%). CI on PR #115: all 6 checks green.