Debug Tracing

Pass p_debug => true on a send (or ask your DBA to set debug on the whole profile) and the pg_relay Processor writes a step-by-step trace outside the delivery transaction — visible live while a send is in flight, and preserved even if the attempt itself rolls back.

SELECT pgrelay_notifier.send('mailer', ARRAY['[email protected]'], 'Test', 'body', p_debug := true);

SELECT * FROM pgrelay_notifier.get_trace(42);
--  step        │ detail
--  claimed     │ queue id 7, channel notifications, attempt 1
--  fetched     │ transport smtp
--  sent        │ provider_ref <pgrelay-…>, elapsed_ms 210
--  committed   │ status sent

Reading a trace

Step	Appears when
claimed	The Processor picked the event off the queue
fetched	The message content was read (names the transport)
sent	The provider accepted it (provider_ref, elapsed_ms)
send_failed	The provider rejected it or the connection failed — names the failure class
committed	The attempt's final status was written

A hung send shows claimed/fetched with no sent yet — you are watching it hang, in real time, on a server you don't control. That's the whole point of the trace being written outside the delivery transaction: a wedged attempt is visible while it's wedged, not only after it eventually times out.

Per-message vs. per-profile

p_debug => true on one call traces just that message — the usual choice when you're chasing a specific delivery problem. If your DBA sets debug = true on the whole profile, every message through it traces by default; an explicit p_debug on a call always overrides the profile's setting, in either direction.

---