Watching Your Cluster

Which node is currently the leader / adopter

This is the lowest-numbered live write-master — the node that receives a dead node's traffic. There is no dedicated view for this; run:

-- the lowest-ordered node whose replication slot is active (best-effort; validate the
-- exact spock.node <-> slot mapping for your Spock version)
SELECT min(n.node_id) AS current_lowest_live_master
FROM spock.node n
WHERE EXISTS (
    SELECT 1 FROM pg_replication_slots s
    WHERE s.active AND s.slot_name LIKE 'spk_%' || n.node_name || '%'
);

Adoption events

These log as adopted (a warning, with a rows count) and, at startup, as startup_adopted.

Mode transitions

These log as primary_active / standby_waiting (in single mode) and leader_acquired / leader_yielded (in leader mode).

Cluster-wide audit

Because pgrelay.log is replicated and uses snowflake IDs, a query against pgrelay.log on any node returns every node's dispatch history — you do not need to check each node separately.

Stuck node-restricted rows

pgrelay.queue_stats()'s pending_restricted column (see Managing Channels in the User Guide) counts undispatched, node-pinned rows regardless of their run_at/expire_at values. A steadily growing value here — or a growing oldest_pending alongside it — is the alert that a node is down, or has been permanently decommissioned. See Node-Restricted Channels.

---

Continue to The Split-Brain Risk — the one failure mode conservative adoption cannot fully protect you from.