From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Shay Rojansky <roji(at)roji(dot)org> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed change to make cancellations safe |
Date: | 2016-04-26 21:20:44 |
Message-ID: | CA+TgmoZbUs4TJZ_Rx4yXafc98etKQSJaXZKgNwqVmv8w1ufM+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 25, 2016 at 12:16 PM, Shay Rojansky <roji(at)roji(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-26 21:25:18 | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Previous Message | Tom Lane | 2016-04-26 21:06:13 | Re: EXPLAIN VERBOSE with parallel Aggregate |