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
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 |