Skip to content
HeliosDB HeliosProxy

Impossible Query Demo

Impossible Query Demo

A 60-second demo of one specific, real scenario: the primary is SIGKILLed while a transaction is open but before the client issues its COMMIT. In that scenario tr_mode = "transaction" replays the uncommitted transaction on the new primary and the COMMIT succeeds, with no error reaching the client.

Read the scope literally. This demo does not claim that every failure is recoverable — see what Transaction Replay refuses to do. Had the kill landed while the COMMIT itself was in flight, the client would get SQLSTATE 08007 and nothing would be retried.

What This Proves

  • Transaction Replay (TR) records the statements of an open transaction and replays them on a new primary after failover, verifying each replayed response against what the client already saw.
  • The client sees a successful COMMIT even though the original primary was killed with SIGKILL while the transaction was open — because the fault preceded the COMMIT.
  • Failover detection + promotion + replay happens in under 15 seconds, under the single write_timeout_secs deadline.
  • TR needs no cargo feature and no application change.

Prerequisites

  • Docker and Docker Compose
  • psql (PostgreSQL client) installed locally
  • curl and python3 (for admin API output formatting)

How to Run

Terminal window
# Interactive mode (pauses between steps for live demos)
./demo.sh


# Automatic mode (runs straight through)
./demo.sh --auto

What Happens

  1. A 2-node PostgreSQL cluster starts (1 primary + 1 streaming standby)
  2. HeliosProxy connects to both nodes with Transaction Replay enabled
  3. A client opens a transaction through the proxy: BEGIN, INSERT, UPDATE
  4. The primary is killed with docker kill (simulating hardware failure)
  5. The client issues COMMIT — HeliosProxy detects the failure, promotes the standby, and replays the recorded transaction on the new primary. Note the ordering: the kill happens in step 4, so the COMMIT in step 5 is issued against an already-failed backend rather than being in flight when it dies
  6. COMMIT succeeds. A SELECT confirms the data exists.

Expected Output

  • Steps 1-3: Cluster starts, transaction opens normally
  • Step 4: Primary is killed
  • Step 6: COMMIT succeeds (typically within 2-10 seconds)
  • Step 7: SELECT returns the inserted order and updated inventory
  • Step 9: Summary shows zero errors for this scenario

What to Look For

  • The commit latency — how long the client waited for the replay to complete
  • The proxy logs (docker compose logs heliosproxy) show the failover detection, standby promotion, and transaction replay in real-time
  • After failover, the admin API (/nodes) shows the former standby as the new primary

Cleanup

The demo cleans up automatically on exit. To clean up manually:

Terminal window
docker compose down -v --remove-orphans