Re: Proposed change to make cancellations safe - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposed change to make cancellations safe
Date
Msg-id CA+TgmoZbUs4TJZ_Rx4yXafc98etKQSJaXZKgNwqVmv8w1ufM+w@mail.gmail.com
Whole thread Raw
In response to Re: Proposed change to make cancellations safe  (Shay Rojansky <roji@roji.org>)
Responses Re: Proposed change to make cancellations safe  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Apr 25, 2016 at 12:16 PM, Shay Rojansky <roji@roji.org> 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
> mass for a new protocol and agreement that PostgreSQL is going for it I'd be
> happy to work on it.

I don't immediately see a reason why this couldn't be done as an
isolated change.  Suppose that we change the server to allow a cancel
request to be either 16 bytes or 20 bytes, rather than always 16 bytes
as they are currently.  Clients will need to be careful not to send
the new type of cancel request to a server that is too old to
understand it, but since they've got an active connection,
server_version will have been previously reported.

More generally, as long as new protocol bits are client-initiated, I
don't think we really need to bump the protocol version.  If we want
to change the kinds of responses the server sends or structurally
change the format of protocol messages or deprecate messages that
exist now, then we do.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: EXPLAIN VERBOSE with parallel Aggregate
Next
From: Robert Haas
Date:
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions