Cancel race condition

From: Shay Rojansky <roji(at)roji(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Cancel race condition
Date: 2015-06-07 20:59:32
Message-ID: CADT4RqAk0E10=9bA8V+uu0Dq9tR+Pn8x+ptQBXfC1FBiVH3MFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi everyone.

I'm working on Npgsql and have run into a race condition when cancelling.
The issue is described in the following 10-year-old thread, and I'd like to
make sure things are still the same:
http://www.postgresql.org/message-id/27126.1126649920@sss.pgh.pa.us

My questions/comments:

- Does PostgreSQL *guarantee* that once the connection used to send the
cancellation request is closed by the server, the cancellation has been
delivered (as mentioned by Tom)? In other words, should I be designing a
.NET driver around this behavior?
- If so, may I suggest to update the protocol docs to reflect this (
http://www.postgresql.org/docs/current/static/protocol-flow.html#AEN103033
)
- I'm not sure if there's some sort of feature/request list for protocol
4, but it may make sense to provide a simpler solution for this problem.
One example would be for the client to send some sort of numeric ID
identifying each comment (some autoincrement), and to include that ID when
cancelling. I'm not sure the benefits are worth the extra payload but it
may be useful for other functionality as well (tracking/logging)? Just a
thought.

Thanks,

Shay

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-06-07 21:55:47 Re: Resource Owner reassign Locks
Previous Message Jeff Janes 2015-06-07 20:44:08 Re: Resource Owner reassign Locks