Cancel race condition

Поиск
Список
Период
Сортировка
От Shay Rojansky
Тема Cancel race condition
Дата
Msg-id CADT4RqAk0E10=9bA8V+uu0Dq9tR+Pn8x+ptQBXfC1FBiVH3MFA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Cancel race condition
Список 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 по дате отправления:

Предыдущее
От: Dan Langille
Дата:
Сообщение: Re: could not truncate directory "pg_subtrans": apparent wraparound
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: pg_stat_*_columns?