Skip to content

Version 1.1: What's New

Version 1.1 is the current, and only supported, release of pg_relay. This chapter follows the standard Keep a Changelog format, and pg_relay follows Semantic Versioning (a widely used convention where the version number itself signals how big a change is).

It brings four headline features: per-channel dispatch concurrency, Processor fleet control (pause, resume, and reload without a restart), support for sending notifications out of the database via the companion pg_relay_notifier extension, and a small generic options store (pgrelay.options) for database-administrator-configurable settings.

If you are upgrading an existing installation, run ALTER EXTENSION pg_relay UPDATE; — see Installing the Extension in the User Guide.

Added

  • pg_relay_notifier compatibility — pg_relay 1.1 works with pg_relay_notifier 1.0, which handles SMTP email and Microsoft 365 email via the Graph API. The Processor routes 'notify' action-type events through a small, documented interface: the queue payload is a reference into the notifier's own tables, the Processor fetches the message through pgrelay_notifier.fetch(), delivers it, and writes the outcome back through pgrelay_notifier.set_status(). The whole claim-fetch-send-status sequence runs in one held transaction, so delivery is at-least-once, and concurrency_mode applies to notification channels exactly as it does to SQL channels. See pg_relay_notifier compatibility in the Technical Guide.
  • pgrelay.processor_control — a single-row, declarative record of fleet state: a reload_token (a signal that triggers a reload whenever it changes) and a desired_state/pause_until pair (which sets whether the fleet should be running or paused). It is changed only through functions, and every Processor observes it once a second. See Fleet control in the Technical Guide.
  • pgrelay.queue_probe() — the Processor's combined per-tick check, returning whether work exists, the current reload token, and the current pause state, all in one round trip.
  • pgrelay.request_reload() — tells every Processor to reload (reconnect, re-read the application registry, re-run its startup checks) at its next check-in. This can also be triggered through the event queue itself, using a reserved action type — schedulable, and recorded in the audit log just like any other event.
  • pgrelay.start() / pgrelay.stop() / pgrelay.pause_for(seconds) / pgrelay.pause_to(timestamp) — fleet pause control. A paused Processor finishes whatever it is already doing, keeps checking in, but claims no new work.
  • Application-registry startup check — the Processor now calls pgrelay.list_applications() at startup and refuses to start if that call fails, catching a mismatch between the installed extension and the Processor binary immediately, with a clear, actionable message.
  • More thorough startup checks — when pg_relay_notifier is installed, preflight() now also checks its schema, its interface functions, and the pgrelay role's permission to call them (all as warnings, never as something that blocks ordinary SQL processing).
  • pgrelay.actions.concurrency_mode — per-channel dispatch concurrency control: 'concurrent' (the default — no restriction, identical to how pg_relay always behaved), 'channel' (at most one event for the whole channel in flight at once, strictly in queued order), and 'channel_payload' (at most one event per channel-and-payload combination in flight; different payloads still run at the same time as each other). See Controlling concurrency in the User Guide.
  • pgrelay.queue_stats() — a new monitoring function giving you an at-a-glance view of queue health and recent throughput, per channel. See Managing Channels in the User Guide.
  • Node-restricted channels — a per-channel setting for actions with node-local side effects, such as a materialised view refresh. See the Multi-Master Deployment book.
  • pgrelay.options — a generic, private key/value settings table for pg_relay itself, and for companion applications or your own code, to persist configurable options. Purely additive — v1.1 does not read or write any option itself.
  • A larger automated test suite, including the very upgrade path that brings existing installs to 1.1, and twelve new tests covering the new dispatch-concurrency behaviour.

Changed

  • pgrelay.register() and pgrelay.update() gained the new p_concurrency_mode and p_node_restricted parameters. If you are upgrading: these two functions are recreated by the upgrade process, which resets any per-role grants made directly on them — re-run pgrelay.grant_user(role) for each of your management roles afterwards. pgrelay.queue_stats() is likewise recreated (it gained a new pending_restricted column) — re-grant it to your monitoring roles too.
  • pgrelay.notify()'s duplicate-suppression rule was extended to also consider which node an event is pinned to. This makes no difference at all for unrestricted channels; for node-restricted ones, it means deduplication happens per node rather than across the whole cluster.
  • The Processor now refuses to start in --mode=multi-node/leader if the per-node ID setting has not been configured — see Getting Ready in the Multi-Master Deployment book.
  • pgrelay.grant_relay() and pgrelay.grant_user() were both extended to cover the new fleet-control functions.
  • Multi-master support, via the new --mode parameter (single | multi-node | leader; default single). Full detail is in the dedicated Multi-Master Deployment book. Single-node deployments — --mode=single, the default — are entirely unaffected by any of this.
  • The Go toolchain used to build the Processor was updated to a current, supported release, picking up security fixes relevant to the SMTP, webhook, and Microsoft 365 notification transports. This is a pure currency and security update, with no changes to how you use pg_relay.
  • The GitLab CI (continuous integration — the automated system that builds and tests every change) test matrix gained coverage on an additional Linux distribution, purely to catch packaging issues early. This is testing infrastructure only, not a new supported production platform — see Platform Support in the Technical Guide for what is actually supported.

Continue to Where pg_relay Started for the very first release.