docs: name the per-database role and describe the owner-owned queue schema

docs/ops/deploy.md

@@ -143,18 +143,21 @@ it with `REINDEX INDEX CONCURRENTLY "<index>";` when the database is quiet.
 ### The app's database role
 
 The steps above run as the owner `DATABASE_URL` names: the dump, the
-migrations and, after them, the setup of `healthlog_app`, the role the app
-then connects as ([database-role.md](../self-hosting/database-role.md)). The
-app never runs a migration. A migration that creates a table needs nothing
-more: the setup grants the role every table it lacks before the app starts.
+migrations and, after them, the job queue's own install or migration and the
+setup of `healthlog_app_<database>_<hash>`, the role the app then connects as
+([database-role.md](../self-hosting/database-role.md)). Neither the app nor
+its queue ever runs a migration. A migration that creates a table needs
+nothing more: the setup grants the role every table it lacks before the app
+starts.
 
-On the first start of the release that brings the role, the setup hands the
-existing `pgboss` tables to it, which takes each table's lock for a moment.
-Stop the old container (and a separate worker) before the new one starts, as
-for any update with migrations; a lock that does not come within 15 seconds
-leaves that start on the owner with a notice, and the next start tries again.
-A web container and a worker container that start together wait for each
-other on an advisory lock and derive the same password.
+The queue schema `pgboss` stays the owner's. When an update brings a newer
+pg-boss with a schema migration, the start runs it as the owner, including
+its index builds, before the app starts; on a large queue that start takes as
+long as the builds. Stop the old container (and a separate worker) before the
+new one starts, as for any update with migrations. A web container and a
+worker container that start together wait for each other on an advisory lock
+and derive the same password. Going back to 1.46 runs as the owner, as 1.46
+always did, and finds nothing in the queue schema it did not create.
 
 ### v1.46.0 notes
 

docs/ops/disaster-recovery.md

@@ -148,11 +148,12 @@ different.
    key that does not open the data.
 
 The restore runs as the owner `DATABASE_URL` names, and the restored tables
-belong to it. The app connects as `healthlog_app`
+belong to it. The app connects as its own role,
+`healthlog_app_<database>_<hash>`
 ([database-role.md](../self-hosting/database-role.md)): the start in step 5
-grants that role the restored tables and hands it the queue schema before the
-app runs. A dump carries grants to `healthlog_app`; `db-restore` leaves them
-out (`--no-owner --no-privileges`). Restoring with `pg_restore` by hand, pass
+grants that role the restored tables, the queue's included, before the app
+runs; the queue schema stays the owner's. A dump carries grants to the role;
+`db-restore` leaves them out (`--no-owner --no-privileges`). Restoring with `pg_restore` by hand, pass
 the same two flags, or it fails on a database without the role.
 
 When the dumps are still in the server's `backups` volume (the database