Multi-Master Deployments

pg_relay v1.1 can run its Processor in three modes — single (one primary, the default), multi-node (Spock active-active, each node dispatches its own queue rows), and leader (Spock active-active, one dispatcher cluster-wide). Full details are in pg_relay's own multi-master documentation. This page covers what's specific to pg_relay_notifier.

Nothing to configure

pg_relay_notifier's interface functions (fetch(), set_status(), debug_log()) are called identically regardless of which node's Processor claims a queue row, and the extension never touches pgrelay.queue or pgrelay.log directly — the strict ownership split the interface contract is built on (see the Technical Reference) is exactly why multi-master support requires zero pg_relay_notifier-specific setup. A notify channel works the same way under every --mode.

notification_id is multi-master safe

pgrelay_notifier.notifications.notification_id is generated by pgrelay._next_id() — the same snowflake-style generator pg_relay's own pgrelay.queue.id/pgrelay.log.id use (a millisecond timestamp, a node id, and a per-node sequence, packed into one 63-bit bigint). If you ever replicate pgrelay_notifier's own tables across a multi-master cluster (so a notification composed on one node is visible from another), ids stay globally unique without any additional work — the same technique pg_relay validated for its own queue.

The one real caveat: concurrency_mode = 'channel'

'channel' serialization — "at most one in-flight send, in strict order," used to rate-limit a mailbox or preserve send ordering — is cluster-wide only under --mode=single or --mode=leader. Under --mode=multi-node, each node dispatches its own queue partition independently, so the guarantee only holds per node: two different notifications, enqueued from different nodes at roughly the same moment, can be dispatched by their own nodes in parallel — not because anything is duplicated, but because multi-node groups concurrency by (node, channel), not channel alone.

This isn't a duplicate-delivery risk (at-least-once delivery holds regardless of mode) — it's a throughput/ordering guarantee that multi-node's per-node dispatch partitioning structurally can't provide. If a notify channel exists specifically to rate-limit or serialize access to one external mailbox or relay, run that deployment with --mode=leader (or single), not multi-node.

node_restricted channels don't apply here

pg_relay 1.1 has a per-channel node_restricted flag that pins a channel's queue rows to the node that created them — built for companion applications with genuinely node-local side effects, like refreshing a materialised view whose heap isn't logically replicated (pg_auto_mv is the motivating case). Email delivery has no node-local state — sending from any node achieves the identical result — so notify channels should stay unrestricted (the default), even on a multi-master deployment. create_channel() calls pgrelay.register() with named arguments, so it's forward-compatible with node_restricted if a future need for it ever arises, but there is no reason to set it today.

---