Proposed change to make cancellations safe

From: Shay Rojansky <roji(at)roji(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Proposed change to make cancellations safe
Date: 2016-04-24 12:04:32
Message-ID: CADT4RqAUd7wYYsM9D7GHJnZj3J79D4W=ved2kqM5mVt5cuGHgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-04-24 15:11:45 Re: Proposed change to make cancellations safe
Previous Message Petr Jelinek 2016-04-24 08:12:38 Re: VS 2015 support in src/tools/msvc