1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
//! Postgres connection pool configuration and migration runner.
//!
//! Centralising the pool defaults here means every binary in the crate
//! gets the same connection-acquisition behaviour. Tunable per-call via
//! the builder methods, but the defaults are chosen to be sensible for
//! the typical web-API / worker shape:
//!
//! - 10 connections is enough for a single API node plus a small worker
//! pool. The Postgres `max_connections` ceiling (default 100) leaves
//! headroom for ~10 such pods.
//! - `min_connections = 0` means the pool grows lazily; the first
//! request after idle pays the connection cost. Acceptable for a
//! demo; production may want to set this >0 to absorb load bursts.
//! - 5-second acquire timeout surfaces "the DB is gone" quickly as an
//! error rather than letting handlers hang.
//! - 5-minute idle timeout reclaims connections from a quiet pool so
//! long-running deployments don't accumulate idle handles indefinitely.
use Duration;
use raw_sql;
use ;
/// Connection pool configuration. Construct via [`PoolConfig::from_url`]
/// and modify with the builder methods.
///
/// The fields are public so library consumers can override fields
/// directly without going through the builder when their use case
/// doesn't fit the chain pattern.
/// Open a connection pool against the configured URL.
///
/// Establishing the pool actually opens a connection (lazy initialisation
/// is not used here; `connect_with` eagerly connects to surface
/// configuration errors at startup rather than at first query).
pub async
/// Run the embedded initial schema against the given pool.
///
/// The SQL is embedded at compile time so published crates and installed
/// binaries do not need a separate `migrations/` directory at runtime.
/// The migration itself is idempotent (`IF NOT EXISTS` plus duplicate-type
/// guards), so re-running it against an already-migrated database is safe.
pub async