Skip to content

Check Implementation Functions

The 165 built-in check functions

These aren't documented individually here — each one's display name, rationale, result type, and other metadata live as data in the check catalog itself, which is the authoritative, always-current source. A static copy in this document would go stale the moment a check is added, renumbered, or edited. Browse the catalog directly instead:

SELECT check_id, check_name, result_type, result_unit, rationale
  FROM pghf.checks
 WHERE NOT retired
 ORDER BY check_id;

Or, without needing direct table access, use pghf.list_checks() — see Catalog: Checks.

The contract every check function satisfies

What's true of every check function, built-in or one you've added yourself, is the uniform contract that makes the collection engine (see Collection Engine) fully generic — it has no built-in knowledge of what any individual check actually does:

  • Signature: exactly one parameter, the ID of the current run, returning pghf.check_result — no other parameter list is accepted when registering a check.
  • Return contract: see pghf.check_result. A check with a data prerequisite — for example, a Spock-cluster check that needs the Spock extension installed — checks for it itself and reports itself as skipped; nothing in the collection engine special-cases any category or check.
  • Never raises intentionally: an unhandled exception is caught centrally by the collection engine and logged as an error result, with the underlying database error message recorded as the explanation — a check body doesn't need its own exception handling.
  • Registration: every built-in check is registered automatically by the framework's seeding function; a custom one is registered with pghf.create_check(), or cloned from a built-in with pghf.copy_check() — see Catalog: Checks.

For the full walkthrough of writing one of these yourself, see the Adding Your Own Checks book.

Continue to Collection Engine.