Re: [HACKERS] Proposed change to make cancellations safe

Robert Haas writes: > On Mon, Apr 25, 2016 at 12:16 PM, Shay Rojansky wrote: >> Sure. I'd consider sending in a patch, but as this is a protocol-changing >> feature it seems like working on this before the team "officially" starts >> working on a new

Re: [HACKERS] Proposed change to make cancellations safe

On Mon, Apr 25, 2016 at 12:16 PM, Shay Rojansky wrote: > Sure. I'd consider sending in a patch, but as this is a protocol-changing > feature it seems like working on this before the team "officially" starts > working on a new protocol might be a waste of time. Once there's critical

Re: [HACKERS] Proposed change to make cancellations safe

Shay Rojansky writes: >> We really do need "cancel up to" semantics for reliable behavior. >> Consider the case where the client has sent the query (or thinks it has) >> but the server hasn't received it yet. If the cancel request can arrive >> at the server before the query fully

Re: [HACKERS] Proposed change to make cancellations safe

> > We really do need "cancel up to" semantics for reliable behavior. > Consider the case where the client has sent the query (or thinks it has) > but the server hasn't received it yet. If the cancel request can arrive > at the server before the query fully arrives, and we don't have "cancel >

Re: [HACKERS] Proposed change to make cancellations safe

Shay Rojansky wrote: > BTW it seems it's no longer possible for anyone to add things to the TODO > (no editor privileges). You need to ask for editor privs on pgsql-www. Make sure to mention your community user name. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Proposed change to make cancellations safe

Shay Rojansky writes: >> Issuing bulk cancellations sounds like a bad plan. > I'm not sure why, but at the very least it's a useful thing to have when > batching several statements together and then wanting to cancel them all. We really do need "cancel up to" semantics for

Re: [HACKERS] Proposed change to make cancellations safe

> > I definitely agree that simply tracking message sequence numbers on both >> sides is better. It's also a powerful feature to be able to cancel all >> messages "up to N" - I'm thinking of a scenario where, for example, many >> simple queries are sent and the whole process needs to be cancelled.

Re: [HACKERS] Proposed change to make cancellations safe

On 24 April 2016 at 23:11, Tom Lane wrote: > Have you seen this to be a problem in practice, or is it just > theoretical? I do not recall many, if any, field complaints > about the issue. > It's caused pain for me when working with JDBC in the past. If libpq gets

Re: [HACKERS] Proposed change to make cancellations safe

Simon Riggs writes: > On 24 April 2016 at 17:54, Shay Rojansky wrote: >> I definitely agree that simply tracking message sequence numbers on both >> sides is better. It's also a powerful feature to be able to cancel all >> messages "up to N" - I'm thinking

Re: [HACKERS] Proposed change to make cancellations safe

On 24 April 2016 at 17:54, Shay Rojansky wrote: > I definitely agree that simply tracking message sequence numbers on both > sides is better. It's also a powerful feature to be able to cancel all > messages "up to N" - I'm thinking of a scenario where, for example, many > simple

Re: [HACKERS] Proposed change to make cancellations safe

I definitely agree that simply tracking message sequence numbers on both sides is better. It's also a powerful feature to be able to cancel all messages "up to N" - I'm thinking of a scenario where, for example, many simple queries are sent and the whole process needs to be cancelled. Yes, this

Re: [HACKERS] Proposed change to make cancellations safe

On 24 April 2016 at 13:04, Shay Rojansky wrote: 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

Re: [HACKERS] Proposed change to make cancellations safe

Shay Rojansky writes: > 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. Right ... > A simple fix for this would be to have a sequence number returned in the > BindComplete message. First, that

[HACKERS] Proposed change to make cancellations safe

Hi. A while ago I discussed some reliability issues when using cancellations ( http://www.postgresql.org/message-id/CADT4RqAk0E10=9ba8v+uu0dq9tr+pn8x+ptqbxfc1fbivh3...@mail.gmail.com). Since we were discussing some protocol wire changes recently I'd like to propose one to help with that. The