---
title: "Impossible Query Demo"
---

# Impossible Query Demo

A 60-second demo of one specific, real scenario: the primary is `SIGKILL`ed 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](/docs/proxy/transaction-replay/#what-it-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

```bash
# 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:

```bash
docker compose down -v --remove-orphans
```