Cancel race condition - Mailing list pgsql-hackers

From Shay Rojansky
Subject Cancel race condition
Date
Msg-id CADT4RqAk0E10=9bA8V+uu0Dq9tR+Pn8x+ptQBXfC1FBiVH3MFA@mail.gmail.com
Whole thread Raw
Responses Re: Cancel race condition  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Dan Langille
Date:
Subject: Re: could not truncate directory "pg_subtrans": apparent wraparound
Next
From: Joel Jacobson
Date:
Subject: Re: pg_stat_*_columns?