Glossary¶
Every acronym and piece of technical jargon used across this site, in one place, in plain English. Terms are listed alphabetically. Use the search box at the top of any page to jump straight to a term, or the "On this page" panel on the right to browse this list.
amcheck¶
A PostgreSQL extension that verifies the internal structural integrity of B-tree indexes. One of the built-in checks depends on it being installed — see Checks with an Extension Prerequisite.
Category¶
The second level of pg_health_framework's catalog, scoped to one namespace — for example, "Connection & Availability." See Core Concepts.
Check¶
A single PostgreSQL function, registered in the catalog, that collects one piece of data about your server and records exactly what it observed — with no judgment about whether that's good or bad. See Core Concepts and The Check Contract.
Check ID¶
A check's human-readable identifier, such as PGHF01-006 — built automatically from its namespace code, category code, and a zero-padded run number. See Metadata Columns Explained.
CI (Continuous Integration)¶
An automated system that builds and tests every proposed change to a codebase before it's merged. pg_health_framework uses GitLab CI, which also builds and publishes this documentation site.
Confirmed severity / raw severity¶
Two related values the evaluation engine produces for each check: raw severity is exactly what one run's data says on its own; confirmed severity is the raw severity after debounce is applied. See How Threshold Evaluation Works.
Cron¶
A standard Unix scheduling tool for running a command automatically on a recurring timetable. One common way to schedule pg_health_framework's own runs — see Scheduling Health Checks.
Debounce¶
Requiring a chosen number of consecutive breaching runs before a check's confirmed severity actually reflects the breach, rather than reacting to a single noisy sample. See Debounce: Requiring Consecutive Failures.
Evaluation¶
The record of a single check's judged severity for a single run — the output of the evaluation engine, produced by comparing a raw result against a threshold. See How Threshold Evaluation Works.
Extension (PostgreSQL)¶
An installable package that adds new functionality — tables, functions, types — to a PostgreSQL database. pg_health_framework can install either as a real extension or as a plain SQL script; see Installing pg_health_framework.
JSONB¶
PostgreSQL's binary-optimised storage type for JSON data — structured, JSON-shaped values stored inside an ordinary database column, faster to query than plain JSON text. Used throughout this framework for a check's collected data, especially where a check reports a breakdown rather than a single number. See Metadata Columns Explained.
Namespace¶
The top level of pg_health_framework's catalog — a short code (up to 4 uppercase letters/digits) grouping a set of related checks. The built-in checks all live under one namespace, PGHF; your own checks live under a namespace you choose. See Core Concepts.
NOTIFY / LISTEN¶
A built-in PostgreSQL feature that lets one database session send an asynchronous message to any other session that's listening on a named channel. pg_health_framework's 'notify'-type events use this — see Creating an Event.
ORM (Object-Relational Mapper)¶
A code library, used in application development, that maps an application's own objects onto database tables automatically. Mentioned in this site only as an example of something that can leave behind unexpected extra tables — see Putting It All Together.
pgBackRest¶
A popular open-source backup and restore tool for PostgreSQL. One category of built-in checks covers its configuration and the write-ahead log archiving it depends on — see Using the Seed Catalog.
pg_stat_statements¶
A PostgreSQL extension that tracks execution statistics for every SQL statement run on the server. Several built-in checks depend on it — see Checks with an Extension Prerequisite.
pg_upgrade¶
PostgreSQL's own built-in tool for upgrading a server from one major version to another in place. One category of built-in checks (opt-in, since it needs a target version number) assesses whether a server is ready for this — see Suites.
pg_visibility¶
A PostgreSQL extension that reports on a table's visibility map — an internal structure PostgreSQL uses to skip unnecessary work during vacuuming and index-only scans. One of the built-in checks depends on it being installed — see Checks with an Extension Prerequisite.
PL/pgSQL¶
PostgreSQL's own procedural programming language for writing functions and procedures directly inside the database. Every check, evaluator, and event function in pg_health_framework is written in it.
Procedure versus function (PostgreSQL)¶
Two different kinds of callable database routine. A function is called with SELECT or used inside an expression, and works normally inside a transaction. A procedure is called with a standalone CALL statement, and can commit its own work partway through — which is why several of pg_health_framework's own procedures (the collection engine, the evaluation engine) must be called as a bare CALL, never nested inside your own transaction. See How to Read This Reference.
Raw result¶
One check's collected data for one run — the output of the collection engine, before any judgment has been applied. See Core Concepts.
regprocedure¶
A PostgreSQL data type used to refer directly to one specific function or procedure, including its exact argument list — as opposed to a plain text string, which PostgreSQL wouldn't check until the function was actually called. Used throughout pg_health_framework to register a check's backing function, so a typo or a wrong return type is caught immediately. See Worked Example: A Custom Check.
Retired (check)¶
A check that has been inactivated — excluded from normal runs and removed from every suite it belonged to, but with its past history left untouched. See Inactivating a Check.
Run¶
One actual execution of a suite — collecting data for every check it contains, and (in a separate step) judging that data against thresholds. See Core Concepts.
SECURITY DEFINER / SECURITY INVOKER¶
Two ways a PostgreSQL function can run: SECURITY DEFINER always runs as the function's owner, no matter who calls it; SECURITY INVOKER (the default) runs as whoever actually called it. pg_health_framework uses both deliberately, in different places, as part of its access model. See The Access Model.
Severity¶
The judged outcome of evaluating a check's collected data against a threshold: ok, info, warning, or critical, plus the two non-alert states unknown (the check reported itself as skipped or failed) and not_evaluable (no threshold configured). See How Threshold Evaluation Works.
Spock¶
A PostgreSQL extension, developed by pgEdge, that provides logical multi-master replication — letting more than one database node accept writes at once and keep each other in sync. Several built-in checks specifically cover a Spock cluster's health, and self-skip cleanly on a server without it. See Using the Seed Catalog.
SSL / TLS¶
The standard technology for encrypting a network connection, including a connection to your PostgreSQL server. One of the built-in checks reports whether it's turned on.
Suite¶
A named, ordered list of checks — for example default — that can be run together with a single command. Internally called a "check run." See Core Concepts.
Superuser¶
PostgreSQL's most privileged kind of database role, exempt from all permission checks. One built-in check specifically measures how many login-capable roles are superusers, as a percentage of the total — a security-posture signal. See Using the Seed Catalog.
Synchronous standby¶
A replica server that PostgreSQL waits to confirm has received a transaction before reporting that transaction as committed — as opposed to an asynchronous standby, which it doesn't wait for. Several built-in checks and custom evaluators treat a synchronous standby's replication lag more strictly than an asynchronous one's. See Writing a Custom Evaluator.
Threshold¶
A configured rule describing what a good or bad result looks like for a particular check — the softest, middle, and hardest tiers a numeric value can breach, or which outcome a true/false check should map to a given severity. See How Threshold Evaluation Works.
TOAST (The Oversized-Attribute Storage Technique)¶
PostgreSQL's own mechanism for storing very large field values (a long piece of text, for example) out of line from the main table row, so the row itself stays a manageable size. One category of built-in checks covers TOAST-related health.
UUID (Universally Unique Identifier)¶
A long, randomly generated value used as an identifier, specifically designed so that two different UUIDs generated anywhere, by anyone, will — for all practical purposes — never clash. pg_health_framework uses one for every run's identifier, and for every check's permanent internal identity. See Using the Seed Catalog.
Vacuum¶
PostgreSQL's own background process for reclaiming space left behind by updated or deleted rows, and for preventing transaction ID wraparound (see below). One of the largest categories of built-in checks covers vacuum health.
Visibility map¶
An internal structure PostgreSQL maintains per table, recording which pages contain only rows visible to every transaction — used to speed up vacuuming and certain index-only queries. See the pg_visibility entry above.
WAL (Write-Ahead Log)¶
PostgreSQL's own internal, ordered record of every change made to the database, written before the change itself is applied — the basis for crash recovery and for streaming replication to standby servers. Several categories of built-in checks cover WAL growth, archiving, and replication.
Wraparound¶
A PostgreSQL-specific risk where transaction ID numbers, which are finite, could in principle run out and wrap back around to the beginning — which vacuum's background maintenance work exists specifically to prevent. One of the largest categories of built-in checks covers this directly.
If a term you were looking for is missing, it may be explained inline the first time it appears in the relevant book instead — try the search box at the top of the page.