Skip to main content

Crate pylon_pgcon

Crate pylon_pgcon 

Source
Expand description

Postgres connection pooling and query execution, via tokio-postgres + deadpool-postgres. No dependency on pylon-core or PyO3 — usable as a plain Rust Postgres client crate on its own; pylon-core depends on this crate for execution, not the other way around.

query_raw returns raw tokio_postgres::Rows; wire decodes the composite result column those rows carry into pylon_value::DecodedValue (the shared decode target pylon-cache also stores).

Re-exports§

pub use error::Error;
pub use error::Result;
pub use listener::PgListener;
pub use wire::ExtensionOids;
pub use wire::decode_value;

Modules§

error
The crate’s single error type — deliberately not a boxed dyn std::error::Error, unlike the rest of this crate’s early phases. Error mapping to Pylon’s Python exception hierarchy (pylon.exceptions) needs the Postgres SQLSTATE code ("40001" serialization failure, "40P01" deadlock detected) to pick the right class, and the Python-side _fmt_pg_error needs it to format the message. Erasing into a boxed dyn Error at every ? site — this crate’s original design — throws that code away before it can ever reach the pyo3 boundary.
listener
A dedicated LISTEN/NOTIFY connection. Unlike PgPool’s pooled connections — which are meant to be checked out briefly and returned — a listener has to stay open for as long as the caller cares about notifications, and receives out-of-band NOTIFY messages that arrive independently of any query the caller issues. tokio_postgres models this as a Client (for issuing LISTEN/UNLISTEN/ordinary queries) paired with a Connection that must be polled continuously to drive I/O and to surface AsyncMessage::Notifications — normally that polling is done by spawning the connection future and ignoring everything it yields, but here the poll loop is written by hand instead so each Notification can be handed to on_notification as it arrives.
numeric
PostgreSQL’s binary numeric format, to and from a decimal string.
wire
Recursive decoder from PostgreSQL’s binary wire format into pylon_value::DecodedValue — the shared decode target pylon-cache also stores, so a cache hit and a fresh row decode into the exact same shape.

Structs§

PgConnection
One connection checked out of the pool and held by the caller, with no transaction open — see PgPool::connection.
PgPool
PgTransaction
An explicit transaction on a single connection checked out of the pool. deadpool-postgres’s default recycling method (Fast) does not run any reset query when a connection is returned to the pool — unlike pool release, which always issues ROLLBACK itself if the released connection still has an open transaction. That safety net has to be reproduced here explicitly, or a connection released mid- or aborted-transaction would silently corrupt the next borrower’s session. Hence commit rolls back on its own failure before returning the error, and both commit/rollback consume self so the connection is only ever returned to the pool (via Drop) once it is guaranteed to be back in a clean, non-transactional state.
PoolStatus
Snapshot of a pool’s connection accounting — deadpool’s own Status, re-exported under this crate’s name so callers (the Prometheus gauge sampler in pylon-py) don’t need a direct deadpool_postgres dependency just to read four numbers.

Functions§

set_pool_wait_observer
Installs the pool-wait observer. The first call wins; later ones are ignored, so a process that initialises metrics twice can’t double-count.

Type Aliases§

PoolWaitObserver
Notified with (pool name, time spent waiting) every time a caller acquires a pooled connection.