Documentation
¶
Overview ¶
Package postgres is the V1 Postgres-backed implementation of the observability rollups.Store interface.
It is the durable, multi-node production leg of the persistence triad — the third driver alongside the in-memory reference (memstore) and the SQLite driver. All three share the SAME Store interface and the SAME conformancetest suite; `internal/observability/rollups/conformancetest.Run` is the gate, so this driver ships zero new conformance scenarios.
Storage model (the shape documented in rollups/store.go):
- rollup_rows — one row per (bucket_start, tenant_id, user_id, session_id, model); bucket_start is on the fixed-UTC MINUTE grid and every measure is exact BIGINT (cost in integer micro-units of USD, latency min/max as the per-row folds). The secondary indexes (bucket_start, tenant), (bucket_start, tenant, user), and (tenant) give the bounded window + dimension queries their indexed access path — a Query resolves through WHERE bucket_start >= $1 AND bucket_start < $2 [AND dim = ANY(...)] and coarsens the minute rows in SQL, never a full-table scan.
- rollup_checkpoint — the single-row (id = 1) durable local sequence. ApplyBatch advances it in the SAME transaction as the row deltas, and every mutating operation (ApplyBatch, FenceSession, Rebuild) takes `SELECT ... FOR UPDATE` on this row as its serialization point, so concurrent applies coordinate on the stored sequence: a batch whose checkpoint does not advance the stored sequence is an idempotent no-op, and the whole batch is applied atomically or not at all. This is the conditional sequence/version logic that makes replay safe — it makes NO active-active exactly-once claim (rollups.go: the Store has a single writer, the Projector, and no cross-runtime consistency is promised).
- rollup_fence — the PERMANENT erasure fences. FenceSession deletes the triple's rows AND records the fence; Rebuild clears rows and the checkpoint but NEVER the fence, so an erased session cannot be resurrected by a late event or by reprojection.
All queries are parameterized (no string concatenation into SQL). The driver is safe for concurrent use by N goroutines against a single shared instance: writes serialize on the checkpoint row; reads are plain statements under Postgres MVCC snapshots.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func New ¶
New constructs a Postgres-backed rollups.Store against cfg.DSN, applying the embedded forward-only migrations and probing the connection eagerly so a misconfigured DSN fails loudly at construction, not on the first write.
Errors:
- empty cfg.DSN
- sql.Open / ping / migration-apply failure
The driver is constructed directly (no registration): the production driver aggregator home is a wiring concern for the phase that wires the projector into the runtime (same posture as memstore).
Source Files