Debug query order and races

Control SQL query execution order to investigate transactions and race conditions.

On this page

Pause queries between your application and a development database, inspect their SQL and parameters, and choose when each proceeds. Controlling the order helps you investigate transaction handling and race conditions.

Before you start

Set up a PostgreSQL or MySQL proxy and point your application at it.

Pause the queries you care about

  1. Open the proxy's Breakpoints tab and choose Add breakpoint.
  2. Leave Pause on Before forwarding, so the database hasn't seen the query yet.
  3. Narrow it: Operation UPDATE, SQL contains orders. Leave both empty to pause every query.
  4. Choose Save breakpoints.

Now run the action in your application. The first matching query pauses, your application waits, and the query appears under Paused now.

An UPDATE on orders waiting under Paused now, with 1 paused in the title bar and the sidebarAn UPDATE on orders waiting under Paused now, with 1 paused in the title bar and the sidebar
The query waits under Paused now until you decide.

Decide what happens

Choose the paused query to see its SQL and parameters, then:

  • Continue to send it to the database. The next matching query pauses in turn, so you can step through a whole transaction.
  • Return error… to fail it. On PostgreSQL the database itself raises the error, so the transaction is aborted as it would be for real. Try a deadlock (40P01) or serialization failure (40001) to check that your application retries the whole transaction.
  • Drop connection to cut the connection mid-transaction.

Pause after the database answers

Set Pause to Before response to stop after the database has run the query but before your application gets the result. Deliver result passes it on. Drop connection (lose result) prevents your application from receiving the result. The database has already executed the query. Whether a write was committed depends on the result and transaction state.

Race conditions

To reproduce a race, run the same action from two places, such as two browser tabs, with a breakpoint on the query they both send. Both pause. Continue them in the order you want to test, and see whether your locking or constraints hold.

Pause everything

Pause traffic in the header pauses the next operation on every connection of every running service, without any breakpoints. Resume traffic releases everything.