Upgrading¶

When a new version of pg_relay is released, a cloud deployment is upgraded by applying the updated SQL file and replacing the Processor binary. Because the schema was deployed manually rather than via CREATE EXTENSION, there is no ALTER EXTENSION command available to you here.

Stop the Processor first, to avoid any processing activity during the schema upgrade:

sudo systemctl stop pg_relay

Apply the upgrade script(s). Each release ships upgrade scripts named pg_relay--<from>--<to>.sql. Run whichever script (or scripts) carry your deployment from its current version to the new one — never re-run the base install script against an existing deployment, since it creates the tables and role from scratch and will either fail outright or corrupt your existing state.

Upgrading an earlier deployment to 1.1:

psql -h your-host -U admin_user -d your_database -f sql/pg_relay--1.0--1.1.sql

After the 1.1 upgrade, re-run pgrelay.grant_user(...) for each of your management roles — register() and update() gained a new parameter in 1.1, which resets their per-role grants. You can confirm the deployed version at any time:

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

Replace the binary and restart:

curl -LO https://gitlab.com/pebble-it/pg_relay/-/releases/latest/downloads/pg_relay-linux-x86_64
chmod +x pg_relay-linux-x86_64
sudo mv pg_relay-linux-x86_64 /usr/local/bin/pg_relay
sudo systemctl start pg_relay

For container deployments (ECS Fargate, ACI), rebuild the container image with the new binary, push the updated image to your registry, and update the running service to use the new image.

Support¶

pg_relay is published and maintained by Pebble IT Solutions Pty Ltd, Australia.

Source code and releases: gitlab.com/pebble-it/pg_relay
Issue tracker: gitlab.com/pebble-it/pg_relay/-/issues
Licence: MIT — see the Licence book.