Documentation

Cancels any running statements in the current connection, including COPY, or returns if there is no active query to cancel. Make sure you do not try to consume results of queries you have already sent if you run this, or behaviour is undefined. That means if you had a Stream result and you run this function, you should not further inspect the Stream, and if you had sent a pipeline with multiple queries and you run this function, you should not try to consume the results of any query in that pipeline. Also, PostgreSQL's protocol specifies cancellation requests require opening a new connection to the server, which means parallelism can introduce non-determinism, as such:

forkIO $ query conn "SELECT ..." sendCancellationRequest conn

That the cancellation request _can_ arrive before the query even arrives, so it won't be cancelled, and this _can_ happen even if all the messages of the "SELECT ..." query are sent first. The cancellation request can also arrive after the active query finishes.

Modulo the race condition mentioned above, the database connection should be in a healthy and usable state after this function returns, although keep in mind that cancelling a query inside a transaction is equivalent to that query throwing an error, so this can put transactions in an error state.