Skip to content

Installing on Managed PostgreSQL

Prerequisites

  1. pg_relay is already installed and operational in the target database — via its own managed-install path, since it faces exactly the same constraint. See pg_relay's own cloud setup documentation. The pg_relay Processor must be running and connected to this database.
  2. Admin access to the target database — a role equivalent to rds_superuser (AWS), the admin user (Azure), or cloudsql_superuser (Google Cloud SQL). Use the same role that deployed pg_relay if at all possible — see Application registry self-registration below for why that matters.
  3. psql available on the machine you'll run the setup commands from.
  4. The generated managed-install script. Either build it yourself from a clone of the repository:
git clone https://gitlab.com/pebble-it/pg_relay_notifier.git
cd pg_relay_notifier
make managed
# → install/pg_relay_notifier--managed--1.0.sql

or take the pre-generated file from the same location in a release checkout — it's committed to the repository, not built only on demand.

Step 1 — confirm pg_relay is ready

SELECT COUNT(*) FROM pgrelay.actions;

If this returns a row count (even zero), pg_relay is installed and you can proceed. If it fails with schema "pgrelay" does not exist, install pg_relay first.

SELECT latest_version FROM pgrelay.list_applications() WHERE lower(application_name) = 'pg_relay';

Confirm this reports 1.1.0 or later — pg_relay_notifier's install script checks this itself and fails with a clear message if it doesn't, but it's worth knowing up front.

Step 2 — run the managed install script

psql "$YOUR_DB_URL" -v ON_ERROR_STOP=1 -f install/pg_relay_notifier--managed--1.0.sql

This single file creates the pgrelay_notifier schema and everything in it, registers pg_relay_notifier and the notify action type with pg_relay, seeds profile_defaults, grants the pg_relay Processor role the four interface functions, and asks the running Processor fleet to reload.

Step 3 — verify

SELECT pgrelay_notifier.interface_version();   -- returns 1
SELECT * FROM pgrelay.preflight() WHERE check_name LIKE 'notifier:%';   -- all 'ok'

\dx will not list pg_relay_notifier — that's expected; it isn't registered via CREATE EXTENSION on this path. The check above is the equivalent confirmation.

Application registry self-registration

The managed install script self-registers pg_relay_notifier in pg_relay's application registry (pgrelay.pg_relay_applications), the same way it verifies pg_relay's own version there before proceeding.

pgrelay.register_application() has EXECUTE revoked from PUBLIC — only a superuser-equivalent role, the role that deployed pg_relay, or a role explicitly granted access via pgrelay.grant_user() can call it. Because Prerequisite 2 above already has you use the same role that deployed pg_relay, this is automatic. If you deploy pg_relay_notifier with a different role than the one that deployed pg_relay, grant it access first:

SELECT pgrelay.grant_user('the_role_deploying_pg_relay_notifier');

Without this, the managed install script fails with a plain "permission denied for function register_application" error at the self-registration step.

After installing

Set up at least one delivery endpoint, a channel, and a grant for whoever will be sending — same steps as a CREATE EXTENSION install, covered in the DBA Guide.

Need UTL_MAIL.SEND(...) to work unmodified? The UTL_MAIL Compatibility extension has the identical managed-install path.