Proposed change to make cancellations safe - Mailing list pgsql-hackers

From Shay Rojansky
Subject Proposed change to make cancellations safe
Date
Msg-id CADT4RqAUd7wYYsM9D7GHJnZj3J79D4W=ved2kqM5mVt5cuGHgg@mail.gmail.com
Whole thread Raw
Responses Re: Proposed change to make cancellations safe  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposed change to make cancellations safe  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Hi.

A while ago I discussed some reliability issues when using cancellations (http://www.postgresql.org/message-id/CADT4RqAk0E10=9bA8V+uu0Dq9tR+Pn8x+ptQBXfC1FBiVH3MFA@mail.gmail.com). Since we were discussing some protocol wire changes recently I'd like to propose one to help with that.

The issue I'd like to tackle is the fact that it's not possible to make sure a cancellation request affects a specific query. Since cancellations are totally asynchronous and occur on another socket, they affect whatever query is currently being processed. This makes it possible to inadvertently kill a later query, because by the time the cancellation request is delivered and "applied" an the intended query already completed and a later one gets killed.

A simple fix for this would be to have a sequence number returned in the BindComplete message. When submitting a cancellation request, the frontend would have the option (but not the obligation) to pass such as sequence number to the backend. When cancelling, the backend would make sure the sequence number corresponds to the currently running query.

The only drawback seems to be the increased payload of the BindComplete message (4 bytes, or possibly less if we're really worried about it).

If this makes sense, I'll add it to the TODO wiki.

Shay

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: VS 2015 support in src/tools/msvc
Next
From: Tom Lane
Date:
Subject: Re: Proposed change to make cancellations safe