Preserve PostgreSQL global objects beside database dumps

Give shared roles and tablespaces an explicit recovery step beside per-database archives.

Source facts

A PostgreSQL 17 pg_dumpall export includes cluster-wide objects that individual pg_dump archives omit, including roles and tablespaces. Its globals-only option exports the shared objects without database contents. Producing a complete cluster export and restoring its role definitions commonly require elevated database privileges. The no-role-passwords option deliberately omits role password values; after restoration those roles cannot use password authentication until passwords are assigned. A globals export therefore needs an explicit credential-recovery decision.

Source: PostgreSQL 17 — pg_dumpall.

Applicability

This applies to PostgreSQL 17 recovery plans built around per-database logical archives. It concerns cluster-wide prerequisites, not a substitute for backing up each database’s data.

DSE recommendation

DSE recommends pairing each database-backup policy with an owned global-object export and recording which recovery stage restores it. Protect that export as sensitive administration material. Decide deliberately whether password values are retained or reset during recovery, and document the separate recovery authority required. Include intended tablespace locations and ownership in the build sheet. Avoid assuming that restoring an application’s tables also reconstructs every role and filesystem prerequisite its owners depend on.

Verification

Build an isolated empty cluster and rehearse the global-object stage before the selected database restore. Check role membership, intended ownership, tablespace paths, and the planned authentication-reset procedure. Record any deliberate differences from production so they are not mistaken for missing backup content.

Official reference

PostgreSQL 17 — pg_dumpall. Reviewed October 15, 2026.