Cancel message

[davecramer]

You mention that cancel will be replaced with stop. However cancel actually cancels the query on the backend. How will that be accomplished?

[arkstack-dev]

Good catch the spec is underspecified on this and §7 should make the mechanism more explicit.

The short answer: STOP_SENDING with PG_CANCEL is the in-band signal to the server's QUIC layer that "this session wants to cancel its current query." The server's QUIC layer then triggers the same backend-side cancellation routine that fires today when postmaster receives a valid CancelRequest - i.e., the backend process executing the query receives SIGINT (in stock PG), its handler sets QueryCancelPending, and the next CHECK_FOR_INTERRUPTS() call turns that into ERROR: canceling statement due to user request.

Nothing about the backend-side mechanism changes. What changes is the routing:

• Under TCP+TLS, the client opens a second connection to postmaster, which has the (PID, secret) → backend process mapping and forwards SIGINT.
• Under this binding, STOP_SENDING arrives on a stream that the server already owns and maps to a specific backend. No second connection, no (PID, secret), no L4 routing ambiguity. The postmaster's role as a cancel-router goes away but its role as the thing that actually sends SIGINT to the backend process doesn't.

For a proxy-model server (§9), the proxy still has classic v3 TCP connections to the backing PostgreSQL, including the BackendKeyData it received at session start. When STOP_SENDING arrives on a stream, the proxy maps stream → backend TCP connection, opens a secondary TCP to that PostgreSQL instance's postmaster, and issues a standard CancelRequest with the stored (PID, secret). The proxy speaks QUIC to clients and classic v3 to PostgreSQL, doing the translation without PostgreSQL itself needing to change.

One thing worth mentioning since you raised the backend-side question: §7 already addresses the race between query completion and cancel arrival if STOP_SENDING reaches the server when no query is running on that stream, it's a no-op (paragraph 2 of §7). With the cancel signal in-band on the same stream as the query, the ordering guarantee is structural rather than best-effort.

You're right that §7 doesn't say any of this clearly. Will update §7 with the routing-vs-mechanism distinction explicit, and promote
parts of §9 to normative for the proxy-mode translation.

Thanks - this is exactly the kind of pushback the spec needs before v1.0.