Тема: postgresql
-
Managing PostgreSQL extensions: installing, versioning, updating and dumping them
An extension packages SQL objects and often a shared library under one name with a control file and versioned scripts; CREATE EXTENSION installs it per database, ALTER EXTENSION UPDATE applies the author's update scripts, and pg_dump emits only the CREATE EXTENSION line. Keep the installed files, the catalog version and the loaded library in step, especially across package upgrades and pg_upgrade.
-
Designing an append-only time-series table in PostgreSQL
Store measurements in a table partitioned by time range with timestamptz, a composite key of series and time, indexes matched to the query pattern (B-tree per series, BRIN for whole-table time scans) and retention implemented by detaching and dropping partitions instead of DELETE; the choices follow from rows arriving in time order and leaving in whole time slices.
-
Storing derived data in PostgreSQL: generated columns versus materialized views
A generated column derives one value per row from that row alone, either virtual (computed on read) or stored (computed on write), and may use only immutable expressions; a materialized view stores the result of any query and is only as fresh as its last REFRESH. Use stored generated columns for per-row normalisation that should be indexed, materialized views for expensive aggregates that may lag, and a maintained summary table when neither fits.
-
VACUUM, autovacuum and table bloat
PostgreSQL's MVCC leaves dead row versions behind after updates and deletes; VACUUM reclaims them and maintains statistics and transaction-id wraparound protection. Autovacuum should stay on and be tuned for busy tables.
-
Ephemeral databases in containers for integration tests
Start the real database engine in a throwaway container per test run, keep its data on memory, apply migrations once to a template database and copy it per test file; tests then exercise the real planner, constraints and isolation behaviour instead of an in-memory substitute.
-
Transaction isolation levels in practice
Read committed, repeatable read and serializable trade concurrency for consistency; knowing which anomalies each level allows decides when to add explicit locks or retries.
-
Datenbankänderungen ohne Ausfall: Expand und Contract
Ein Schema in drei einzeln auslieferbaren Schritten ändern: erweitern (neue Spalte oder Tabelle anlegen, alte behalten), migrieren (doppelt schreiben und in Häppchen nachfüllen), zusammenziehen (Altes entfernen, sobald aller Code das Neue nutzt); lange Sperren vermeiden, indem keine Tabelle in einem Statement umgeschrieben wird und lock_timeout jede Wartezeit begrenzt.
-
Common table expressions and recursive queries with WITH
WITH names a subquery for the rest of a statement; WITH RECURSIVE evaluates a non-recursive term, then repeats a recursive term until it produces no new rows, which walks trees and graphs of any depth in one query. Single-use, side-effect-free CTEs are folded into the outer query unless MATERIALIZED is written, and SEARCH and CYCLE clauses handle ordering and loops.
-
JSONB columns: what they are good for and when a column is better
jsonb stores parsed JSON in a binary form that can be indexed with GIN and queried with containment and path operators; it suits sparse, externally defined or genuinely variable attributes. Data with a fixed shape, data that needs constraints, foreign keys or per-field updates, and large frequently changed documents belong in ordinary columns.
-
Database connection pooling and its limits
Each PostgreSQL connection is a process with memory cost; applications should keep a small pool sized to real concurrency, set acquisition timeouts, and never let request handlers open ad hoc connections.
-
Measured PostgreSQL SKIP LOCKED claims with four concurrent queue consumers
Four concurrent transactions each claimed 25 synthetic jobs in PostgreSQL 16.15. The returned 100 IDs were unique and no jobs remained unclaimed; this verifies one bounded claim phase, not exactly-once processing or broker replacement.
-
Planner statistics in PostgreSQL: statistics targets, correlated columns and misestimates
The planner estimates row counts from per-column statistics that ANALYZE samples (most common values, histograms, distinct counts) and assumes independent columns; misestimates come from stale statistics, skewed columns with too few entries, correlated columns and expressions. Raise the statistics target on specific columns, create extended statistics for correlated columns or expressions, re-analyze, and compare estimated with actual rows.
-
NULL in SQL: dreiwertige Logik und ihre Fallen
NULL bedeutet unbekannt, darum ergibt jeder Vergleich mit NULL weder wahr noch falsch, sondern unbekannt; WHERE verwirft unbekannte Zeilen, NOT IN mit einem NULL trifft nichts, Aggregate überspringen NULL, und ein Unique-Constraint lässt mehrere NULL zu. IS NULL, IS DISTINCT FROM und COALESCE bewusst einsetzen.
-
Schema migrations run with a short lock_timeout and automatic retry cause fewer deploy-time incidents than migrations without one
Hypothesis: because most ALTER TABLE forms take an ACCESS EXCLUSIVE lock that queues behind any long transaction while blocking every later query, migrations executed with a lock_timeout of a few seconds and a bounded retry loop produce fewer and shorter deploy-time outages than the same migrations run with the default unlimited wait, at the cost of a few migrations that need a manual rerun.
-
Row-level security policies reduce cross-tenant data leaks compared with application-side filtering
Hypothesis: multi-tenant services that enforce tenant isolation with PostgreSQL row-level security policies (a per-connection tenant setting checked by the database) have fewer cross-tenant exposure bugs than services that add a tenant_id predicate to every query, because a query that forgets the tenant predicate still sees only the current tenant's rows, and a request that never sets the tenant gets nothing or an error instead of every tenant's rows.
-
Savepoints and the aborted-transaction state in PostgreSQL
After any error inside a transaction block PostgreSQL rejects every further command until the block is rolled back; a savepoint set before a risky statement lets ROLLBACK TO SAVEPOINT discard only that part and continue. Use savepoints deliberately and sparingly, and make error handlers roll back instead of retrying on the same connection.
-
Logical replication in PostgreSQL: publications, subscriptions and how it differs from streaming replication
Streaming (physical) replication ships write-ahead log to a byte-identical standby of the same major version and architecture; logical replication publishes row changes from selected tables to a subscriber that may run a different major version and can hold its own data. Logical replication needs a replica identity, carries neither DDL nor sequence values, and its slot retains WAL on the publisher while the subscriber is behind.
-
Read replicas and replication lag: what stale reads look like and how to bound them
A streaming replica applies the primary's log with some delay, so a read right after a write may not see the write. Route reads by how much staleness each caller tolerates, use synchronous replication modes only where their latency is acceptable, and understand that replaying the log can cancel long queries on the replica.
-
Long-running and idle-in-transaction sessions in PostgreSQL: what they block and how to bound them
An open transaction holds its locks and pins the xmin horizon, so VACUUM cannot remove rows deleted after it began and DDL queues behind it; the worst case is a session idle in transaction because a client never committed. Find them in pg_stat_activity by xact_start and state, and bound them per role with idle_in_transaction_session_timeout, transaction_timeout and statement_timeout.
-
Schema conventions for a new PostgreSQL database: names, identifiers, timestamps and text
Decide a handful of conventions before the first migration: lower-case snake_case names that never need quoting, one id strategy applied everywhere, timestamptz for every point in time with created_at on every table, text instead of varchar(n), and explicit NOT NULL and foreign keys; write them down so every later migration follows them.
Машиночитаемо: JSON