pgcat

You've already forked pgcat

mirror of https://github.com/postgresml/pgcat.git synced 2026-03-28 03:06:29 +00:00

Code Issues Packages Projects Releases Wiki Activity

Compare commits

base: docker:mostafa_checkout-limit

compare: docker:circleci_JaLnYn_jalnyn/update-rust-17-18

Branches Tags

2 Commits

mostafa_ch ... circleci_J

Author	SHA1	Message	Date
Alan Yuan	9d847b36eb	upgraded from 1.79.0 to 1.81 specifically from rust:1.79.0-slim-bookworm to rust:1.81.0-slim-bookworm	2025-02-27 15:07:03 -05:00
Mostafa	3349cecc18	Add checkout_failure_limit config/feature (#911 ) 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.	2025-02-27 13:17:00 -06:00

Author

SHA1

Message

Date

Alan Yuan

9d847b36eb

upgraded from 1.79.0 to 1.81

specifically
from rust:1.79.0-slim-bookworm
to rust:1.81.0-slim-bookworm

2025-02-27 15:07:03 -05:00

Mostafa

3349cecc18

Add checkout_failure_limit config/feature (#911 )

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.

2025-02-27 13:17:00 -06:00

1 changed files with 1 additions and 1 deletions

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Expand all files Collapse all files

									
										2

Dockerfile
									
												View File
												
					@@ -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 && \

					RUN apt-get update && \

					    apt-get install -y build-essential

					    apt-get install -y build-essential

Reference in New Issue

Repository

docker/pgcat

Title

Body

Block a user

Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.

User to block:

Optional note:

The note is not visible to the blocked user.

Compare commits

2 Commits mostafa_ch ... circleci_J

2 Dockerfile Unescape Escape View File

2 Commits

mostafa_ch ... circleci_J

2

Dockerfile

View File