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.
Active-active¶
A cluster arrangement where more than one database node can accept writes at the same time (as opposed to a traditional primary/standby setup, where only one node ever accepts writes). See the Multi-Master Deployment book.
Adoption (multi-master)¶
In pg_relay's multi-node mode, the process by which a live node takes over dispatching a dead node's queued events, after waiting long enough to be confident the other node has genuinely failed. See Deciding If a Node Is Dead.
Advisory lock¶
A PostgreSQL locking mechanism your own application controls directly, rather than one PostgreSQL applies automatically to protect a row or table. pg_relay uses a session-level advisory lock so each Processor can claim a unique "instance slot" for its logs. See The Processor.
API (Application Programming Interface)¶
A defined way for one piece of software to talk to another — for example, Microsoft's Graph API, which pg_relay_notifier uses to send Microsoft 365 email.
ARN (Amazon Resource Name)¶
AWS's standard format for uniquely identifying a specific cloud resource, such as a secret stored in Secrets Manager. See Running the Processor.
Backoff¶
Waiting progressively longer between retry attempts, rather than retrying instantly and repeatedly. pg_relay's retry schedule is 3 seconds, then 5, then 10 — see Retry Policy.
CA certificate (Certificate Authority)¶
A trusted organisation that issues digital certificates used to verify a server's identity over an encrypted connection. Relevant to PGSSLROOTCERT when using verify-full SSL mode.
CGO_ENABLED¶
A Go build-time setting. CGO_ENABLED=0 produces a fully self-contained binary with no dependency on the local C library, which is what makes cross-compiling the Processor for other platforms possible from a single machine. See Building from Source.
Channel (pg_relay)¶
A named event type you define yourself, with one registered SQL action attached to it. See Core Concepts.
CI (Continuous Integration)¶
An automated system that builds and tests every proposed change to a codebase before it is merged. pg_relay uses GitLab CI.
Deadlock¶
A situation where two database operations are each waiting for the other to finish, so neither can proceed. PostgreSQL detects this and cancels one of them; pg_relay automatically retries an action that fails this way. See Retry Policy.
Deduplication (dedup)¶
Suppressing a new event if an identical one is already sitting in the queue, so only one copy actually runs. See Sending Events.
ECS / Fargate (Elastic Container Service)¶
AWS's service for running containers. "Fargate" is the option within ECS that runs your container without you having to manage any underlying servers yourself. See Running the Processor.
ETL (Extract, Transform, Load)¶
The process of pulling data out of one system, reshaping it, and loading it into another — commonly a data warehouse. See Common Uses for pg_relay.
FOR UPDATE SKIP LOCKED¶
A PostgreSQL locking technique that lets several concurrent processes each grab a different row from the same table, without waiting on each other or picking the same row twice. This is the mechanism that lets multiple pg_relay Processors and workers safely share the same queue. See Workers.
FQDN (Fully Qualified Domain Name)¶
A complete, unambiguous hostname — for example, your-server.postgres.database.azure.com — as opposed to a short or relative name.
GRANT / REVOKE / EXECUTE¶
PostgreSQL's own permission commands. GRANT gives a role permission to do something (such as call a function, with EXECUTE); REVOKE takes that permission away. See Granting Permissions.
HA (High Availability)¶
An architecture designed so that a service keeps running even if one part of it fails — typically by having a standby ready to take over. See High Availability.
IAM (Identity and Access Management)¶
AWS's and Google Cloud's system for controlling who — and what software — is allowed to do what, to which resources.
Idempotent¶
Describes an operation that produces the same end result no matter how many times it runs — so running it twice by accident causes no harm. pg_relay recommends writing your action functions this way, since events are delivered "at least once". See Recommended action pattern and the worked example's use of ON CONFLICT in Building the Example Schema.
JSON (JavaScript Object Notation)¶
A common, human-readable text format for structured data — for example, {"order_id": 42, "tracking": "ABC123"}. Widely used as an event payload format in pg_relay.
JSONB¶
PostgreSQL's binary-optimised storage type for JSON data — faster to query than plain JSON text, and what the worked example's tables use to store event data.
Leader election¶
In pg_relay's leader multi-master mode, the process by which exactly one node is chosen to dispatch every unrestricted event across the whole cluster. See How Each Mode Works.
libpq¶
PostgreSQL's own client connection library. The Processor reads its connection settings (PGHOST, PGPORT, and so on) from the same environment variables every standard PostgreSQL tool uses. See The Processor.
LISTEN/NOTIFY¶
A built-in PostgreSQL feature that lets one database session instantly wake up another. pg_relay deliberately does not use this — see Why there is no LISTEN/NOTIFY.
Materialised view¶
A table-like database object that stores the saved result of a query, rather than recalculating that result every time it is read. Refreshing it updates the stored result. See Common Uses for pg_relay.
OAuth¶
A standard way for one application to be granted limited access to another service on a user's behalf, without ever seeing that user's actual password. Used by the Microsoft Graph API integration in pg_relay_notifier.
Payload (pg_relay)¶
The piece of text sent along with an event, available inside the registered action's SQL as $1. See Core Concepts.
Peer authentication¶
A PostgreSQL authentication method that trusts the operating-system user you are already logged in as, over a local Unix socket connection — no password needed. See Getting Started.
.pgpass / PGPASSFILE¶
A small, permission-locked file that stores database connection passwords, so they never need to appear directly in an environment variable or a command line. See Getting Started.
Polling / poll loop¶
Checking for new work on a regular timer (once a second, for pg_relay), rather than waiting to be woken up by a signal. See Architecture Overview.
Processor (pg_relay)¶
The small program (pg_relay) that runs alongside your database, polls the event queue, and runs each event's registered action. See Core Concepts.
Replication slot¶
A PostgreSQL mechanism that tracks exactly what data a particular replica has and has not yet received, so the primary knows what it still needs to send. Used as the sole liveness signal in pg_relay's multi-master modes. See Deciding If a Node Is Dead.
Role (PostgreSQL)¶
PostgreSQL's term for a database user account (or a group of them). pg_relay creates a tightly-limited role called pgrelay for the Processor to connect as. See The Security Model.
Savepoint¶
A checkpoint set inside a larger database transaction, which lets just the work since that checkpoint be undone, without rolling back everything else in the transaction too. pg_relay uses one around every action it runs. See The Security Model.
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_relay uses both deliberately, in different places, as part of its security model. See The Security Model.
SIGTERM / SIGINT¶
The standard Unix signals meaning "please shut down cleanly" (SIGTERM, sent by systemctl stop) and "stop now" (SIGINT, sent by Ctrl-C). See The Processor.
Serialization failure¶
A transient PostgreSQL error raised when two concurrent transactions conflict in a way that means they cannot both safely succeed. One of pg_relay's two automatically-retried error types. See Retry Policy.
Session-mode / transaction-mode pooler¶
Two different ways a connection pooler can share a smaller set of real database connections across many clients. Session mode pins one real connection to your session for as long as it lasts; transaction mode hands the connection back after every transaction, which breaks pg_relay's Processor. See Connection Poolers.
Snowflake ID¶
A type of unique identifier that is time-ordered and safe to generate independently on several different machines at once, without ever colliding. pg_relay uses these for its queue and log row IDs, which is what makes those tables safe to replicate in a multi-master cluster. See Database Tables Reference.
Spock (and BDR / pgactive)¶
PostgreSQL extensions that provide logical multi-master replication — letting more than one database node accept writes at once, and keep each other in sync. pg_relay's multi-master modes are built against Spock specifically. See the Multi-Master Deployment book.
Split-brain¶
The situation where a network problem splits a cluster into two groups that can no longer talk to each other, and both sides keep operating independently — risking the same work being done twice. See The Split-Brain Risk.
SQL (Structured Query Language)¶
The standard language used to read from and write to a relational database like PostgreSQL. pg_relay's channel actions are, by default, plain SQL statements.
SQLSTATE¶
PostgreSQL's standard error-code system. pg_relay only automatically retries two specific "class 40" SQLSTATE codes — see Retry Policy.
SSL / TLS¶
The standard technology for encrypting a network connection — including the connection between the Processor and your database. Controlled by the PGSSLMODE environment variable throughout this site.
Systemd¶
The standard service manager used by most modern Linux distributions. It starts a program automatically on boot and restarts it if it ever crashes — pg_relay's recommended way to run the Processor in production. See Installing the Processor.
Trigger (PostgreSQL)¶
A piece of database configuration that automatically runs a chosen function whenever a specified event — an insert, update, or delete — happens on a table. Used throughout the Worked Example to call pgrelay.notify() automatically.
Upsert¶
A single database operation that inserts a new row if none exists yet, or updates the existing one if it does. Short for "update or insert". Used in the worked example's JSON snapshot table.
UUID (Universally Unique Identifier)¶
A long, randomly generated value used as an identifier, specifically chosen so that two different UUIDs generated anywhere, by anyone, will (for all practical purposes) never clash. pg_relay uses one as its fleet "reload token". See The Processor.
VM (Virtual Machine)¶
A complete, software-emulated computer running on top of physical hardware, alongside other VMs — the basic building block of most cloud compute services.
VPC (Virtual Private Cloud)¶
An isolated, private section of a cloud provider's network, within which you place your own servers, databases, and other resources. See Running the Processor.
WAL (Write-Ahead Log)¶
PostgreSQL's own internal, ordered record of every change made to the database. Streaming replication works by shipping this log to standby servers, which is why triggers never fire while a standby is replaying it. See Standby and Replica Databases.
Webhook¶
An automatic HTTP request a system sends to a URL you configure, to notify some other system that something happened. See Sending HTTP webhooks from the database.
Window function¶
A SQL feature that lets a query compare or rank each row against other rows in the same logical group, without collapsing them into a single summary row the way a normal aggregate does. pg_relay uses one to enforce per-channel dispatch concurrency. See Workers.
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.