Terminating query in DataGrip does not terminate query in Redshift


The pattern:


1. Execute a query against Redshift

2. Query immediately hits a Redshift queue

3. Cancel the query in DataGrip by pressing the 'Stop' button multiple times in quick succession. Console reports a java.io.EOFException

4. Reconnect the same console & get new PID via pg_backend_pid()

5. Check Redshift... the original query is still queued for execution


So, my question. What is happening if the Stop button is clicked a bunch of times. If clicked once, it seems to spin for a while and finish more 'gracefully' but kinda slow. If you click multiple times it seems to sever the connection rapidly, but pretty dirty. What is going on here - how come the 'dirty' shutdown doesn't kill the query on Redshift?

Comment actions Permalink

Redshift have confirmed this behaviour. Their findings:

I see a single stop button hit actually opens a new TCP stream over which it sends a QUERY CANCELLATION request using PGSQL extended protocol (details in the link). However, multiple hits on stop button just requests for TCP connection close and clears client socket. The side effect of this is the exception 'java.io.EOFException'.

In brief, multiple hits on stop button does not propagate cancel request to server application layer,  rather just loses client socket therefore the query continues to run. Conversely DataGrip does request cancellation of query when you press the button once via new TCP stream. I would suggest you avoid pressing this button multiple times and wait for feedback from Datagrip end about this behavior.


Based on these findings, it feels like the ability to hit the 'Stop' button multiple times is not a good one, since it results in headless queries wasting cluster resources. Perhaps terminating the connection should be provided via another mechanise, and the stop button is only able to send the query cancellation?


Please sign in to leave a comment.