noop

In a high availability deployment of PgCat, it is possible that a client may land on a container of PgCat that is very busy with clients and as such the new client might be perpetually stuck in checkout failure loop because all connections are used by other clients. This is specially true in session mode pools with long-lived client connections (e.g. FDW connections).

One way to fix this issue is to close client connections after they encounter some number of checkout failure. This will force the client to hit the Network load balancer again, land on a different process/container, try to checkout a connection on the new process/container. if it fails, it is disconnected and tries with another one.

This mechanism is guaranteed to eventually land on a balanced state where all clients are able to find connections provided that the overall number of connections across all containers matches the number of clients.

I was able to reproduce this issue in a control environment and was able to show this PR is able to fix it.

Dockerfile

@@ -1,4 +1,4 @@
-FROM rust:1.79.0-slim-bookworm AS builder
+FROM rust:1.81.0-slim-bookworm AS builder
 
 RUN apt-get update && \
     apt-get install -y build-essential

Dockerfile.ci

@@ -1,4 +1,4 @@
-FROM cimg/rust:1.79.0
+FROM cimg/rust:1.81.0
 COPY --from=sclevine/yj /bin/yj /bin/yj
 RUN /bin/yj -h
 RUN sudo apt-get update && \

src/client.rs

@@ -1331,7 +1331,7 @@ where
                         self.buffer_describe(message).await?;
                     }
 
-                    // Execute
+                    // Execute2
                     // Execute a prepared statement prepared in `P` and bound in `B`.
                     'E' => {
                         self.extended_protocol_data_buffer

tests/docker/Dockerfile

@@ -1,4 +1,4 @@
-FROM rust:bullseye
+FROM rust:1.81.0-slim-bookworm 
 
 COPY --from=sclevine/yj /bin/yj /bin/yj
 RUN /bin/yj -h