Skip to main content

Module backend_pool

Module backend_pool 

Source
Expand description

Data-path backend connection pool for Transaction / Statement pooling modes.

This is the raw-stream pool that actually multiplexes clients onto a bounded set of backend connections — the piece that makes the pool-modes feature do real work on the wire. It is deliberately distinct from crate::pool::manager::ConnectionPoolManager, which models pooling over the higher-level BackendClient message API; the proxy data path forwards raw PostgreSQL-wire bytes, so it needs a pool of authenticated TcpStreams.

§Identity keying (why this is safe)

HeliosProxy authenticates backend connections by passing the client’s own credentials through to PostgreSQL (the client SCRAM handshake is relayed). A parked connection is therefore authenticated as a specific (user, database) principal. The pool keys idle connections by node\0user\0database, so a connection is only ever handed to a client that connected with the same identity — and that client independently authenticated before it could reach the pool. This is exactly PgBouncer’s per-(user,db) pooling model; it does not multiplex distinct users onto one backend identity (that would need proxy-terminated auth with a shared backend credential, which is a separate, larger change).

§Cleanliness

A connection is DISCARD ALL-reset by the caller before it is parked (see the release path in server.rs), so the next borrower — possibly a different client of the same identity — never inherits GUCs, temp tables, prepared statements, or advisory locks. On checkout the connection is liveness-probed so a peer that closed the socket while idle is dropped rather than handed out.

Structs§

BackendIdlePool
A bounded set of idle, authenticated backend connections, partitioned by connection identity. Cheap to clone-share behind an Arc.

Functions§

pool_key
Build the pool key for a (node, user, database) triple. NUL-delimited so the three components can never collide across boundaries.