I agree with this and have had similar issues in the past. I think you can terminate your shell process and that will disconnect the client from pgbouncer, even so ideally control-c should work.

That being said I'm not sure if it is possible to implement this in pgbouncer. There is a part of the code (sbuf_pause) that I believe causes pgbouncer to not listen to clients after they have been queued so control c would not reach pgbouncer until they have been queued. Hopefully someone more knowledgeable will tell me that I'm wrong about this.

Hi @AndrewJackson2020 , Thanks for the response.

Based on my debugging, I observed that when PgBouncer is in a paused state or when clients are in the waiting queue, cancel requests still reach the accept_cancel_request method.

In this method, it checks whether the main_client (for which the cancel request is sent) is linked to a server. If the main_client is not linked, the cancel request client(req) is simply disconnected with the following comment and behavior:

/*
* The client is not linked to a server, which means that no query is
* running that can be cancelled. This likely means the query finished by
 * itself before the cancel request arived to pgbouncer.
 */
if (!main_client->link) {
	disconnect_client(req, false, "cancel request for idle client");
	return;
}

Cancel requests for waiting clients also fall into this category, as they are not linked to a server yet. It might be beneficial to handle these cases more explicitly. For instance, PgBouncer could receive the data, ignore the data, and reset the iobuf of main_client.

This could potentially improve the clarity of the behaviour and avoid confusion when cancel requests are issued for queued clients.

Looking forward to hearing your thoughts on this!

Interesting. It definitely seems feasible then. I would definitely encourage you to submit a PR, I would be happy to test it as this issue has bothered me as well.

Keep in mind much of the logic in the function that you mentioned has to do with the scenario of multiple pgbouncers running behind a load balancer/so_reuseport and making sure the cancel request goes to the right bouncer (or something like that). Not sure if that will impact what you are trying to achieve.

Yeah, this seems like a sensible feature to have. Some thoughts on what flow would probably be needed to make this work:

1. Do the currently existing checks related to peering (i.e. if we don't know the key, forward it to the correct PgBouncer peer)
2. If the client is linked, do what we do now
3. If the client is not linked, check if we are trying to link it:
   a. If we are not trying to link it, ignore the cancel request (it probably arrived after the previous query completed).
   b. If we are trying to link it, continue to 5
4. Send an ErrorResponse
5. Consume messages from the client socket until we reach a Sync/PqMsg_Query/PqMsg_FunctionCall
6. Send a ReadyForQuery message

So basically to support this correctly we need to do the same thing that Postgres would do when receiving and handling a cancel, but without actually having to send anything to Postgres. Relevant postgres protocol docs: https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-CANCELING-REQUESTS

I’ll take a closer look at the workflow suggested by @JelteF and work on a PR for this. Thanks @AndrewJackson2020 and @JelteF , for sharing your insights!