Parity: PostgreSQL reconnect-after-drop is Python-only — port to PHP, Ruby, Node (#236/#242) #244

PostgreSQL reconnect-after-drop is Python-only — bring PHP, Ruby, Node to parity

Python reconnects when the server drops a PostgreSQL connection (#236) and, after the
fix for #242, recovers even when the first reconnect attempt itself fails (a failover
before the new primary answers). PHP, Ruby and Node.js never re-establish a dropped
PostgreSQL link at all — once the server closes the connection (failover, idle-session
reap, pg_terminate_backend), every later statement fails until the process is restarted,
while a health check that does not touch the database keeps the process looking healthy.

This is the exact symptom #236 fixed in Python, still live in the other three.

Adapters to fix

• PHP — Tina4/Database/PostgresAdapter.php (and PdoPostgresAdapter.php if active)
• Ruby — lib/tina4/drivers/postgres_driver.rb
• Node.js — packages/orm/src/adapters/postgres.ts

Acceptance criteria (mirror Python)

1. A statement that hits a server-dropped link reconnects from the original connect
   arguments and retries once — but only when nothing uncommitted went down with it;
   inside an explicit transaction the error surfaces and the next statement runs on a
   new link.
2. A reconnect that itself fails does not wedge the adapter: the link stays "dead" and
   the next statement retries, recovering once a reachable server returns (PostgreSQL reconnect: if the reconnect itself fails, the adapter never recovers (follow-up to #236) #242).
3. A real-PostgreSQL regression test per framework (NO mocks): a real dropped backend,
   a real failed reconnect, real recovery; mutation-proven (red on the old adapter).

References

• Reconnect PostgreSQL after the server drops the connection #236 (Python reconnect-after-drop), PostgreSQL reconnect: if the reconnect itself fails, the adapter never recovers (follow-up to #236) #242 (Python failed-reconnect recovery)

🤖 Generated with Claude Code