Skip to content

Where pg_relay Started

Note

Version 1.1 is the current, and only supported, release of pg_relay — see Version 1.1: What's New. This chapter is kept purely for historical context: it describes what shipped in pg_relay's very first release, before the 1.1 upgrade described in the rest of this site.

pg_relay's first release established the whole shape of the project: a durable event processor for PostgreSQL, where producers enqueue events with pgrelay.notify(), and a companion program — the Processor — polls the durable queue once a second and runs each event's registered action. There was no LISTEN/NOTIFY in the dispatch path from day one; the Processor has always found work by polling, for the reasons explained in Architecture Overview in the Technical Guide.

What the extension provided

  • The action type registry, seeded with 'sql', as the foundation for later extensibility.
  • The channel registry, with case-insensitive names, a per-channel retry limit, and the full set of register / update / enable / disable / unregister / get / list management functions.
  • The durable event queue, written by pgrelay.notify() inside the producer's own transaction, supporting deferred events, expiry, deduplication, and automatic retries with backoff.
  • Per-event processing — the cheap probe, the pending-IDs lookup, and process_one(), which claims one row, runs its action inside a savepoint, writes the audit row, and returns the outcome.
  • The audit log, with one row per processed event.
  • Maintenance functions for purging old log rows and dispatched queue rows.
  • The security model described in The Security Model in the Technical Guide: private tables, SECURITY DEFINER helper functions, a SECURITY INVOKER process_one so action SQL never runs with elevated privileges, and EXECUTE revoked from every role except for notify() and list_action_types().

What the Processor provided

  • A poll-only design: a 1-second ticker that checks the queue and processes each eligible event individually.
  • Routing by action type, so unknown types could be safely rejected rather than silently mishandled — the extensibility hook that later releases build on.
  • Concurrent dispatch via --workers N, and safe work-sharing between multiple Processor instances using FOR UPDATE SKIP LOCKED.
  • Structured JSON logging, with the event payload never included — only correlation identifiers.
  • Automatic reconnection with backoff, and credentials re-read from the environment on every connection, so a rotated credential takes effect without a restart.
  • Cross-platform builds for Linux, macOS, and Windows, on both x86_64 and arm64.

This is the final chapter of the CHANGE LOG. Continue to Contributing to report a bug, or to the Licence book for the legal terms pg_relay is published under.