How to use this checklist
This is the gate a cluster passes before a production workload is allowed to depend on it, and again after any change that alters its topology, its authentication, or its recovery capability.
Run it against the running cluster, with a client on the application’s own network path. Roughly a third of the items cannot be answered by reading configuration, because the question is not what the configuration says but what the system does when somebody asks it for something it should refuse.
Where the numbers come from
Every threshold in this checklist is read from the live system rather
than from a document. pg_settings reports what the running server
believes; a configuration file reports what somebody meant. Where the two
disagree, the live reading wins and the disagreement is itself a finding.
pg_hba_file_rules is preferred over reading pg_hba.conf for the same
reason: it shows what the server parsed, with a non-null error column
for any line it could not.
Items are pass or fail, not partially met
An item nobody has checked is a fail, not an unknown. The distinction matters because “we think that is fine” and “we ran it and it refused” are the same entry in a spreadsheet and very different states of the world.
Where an item cannot be satisfied before go-live, record it as an accepted risk with a named owner and a date. A gate with exceptions that somebody owns is a gate; a gate with exceptions that nobody owns is a document.
Access this needs
A role holding pg_monitor on the cluster, which covers every
statistics view this review reads, and pg_read_all_settings for the
configuration values in pg_settings. Treat that grant as privileged
rather than read-only: pg_monitor includes pg_read_all_stats, and
pg_stat_statements can hold a credential that was passed as a literal.
Two items here read pg_hba_file_rules, and neither predefined role
reaches it. Measured on a stock 18.6 cluster, pg_monitor and
pg_read_all_settings are both refused with permission denied for view pg_hba_file_rules; only a superuser, or a role given SELECT on the
view and EXECUTE on the function behind it, can read it. Arrange
that before the review rather than discovering it during one.
Read access to the host: the data directory listing, the pg_wal
filesystem, the log destination, and the unit or container definition
that starts the server.
Read access to the backup destination and to the most recent restore record. Nothing in this review requires the authority to write anything on the production cluster, and a reviewer who needed it should stop and say so.
What the review produces
A dated record naming the reviewer, the cluster, the PostgreSQL version,
and the disposition of every item. Attach the live readings taken during
the review rather than summarising them: the pg_settings extract for
the non-default parameters, the pg_stat_replication row for each
standby, the archiver counters, and the date and duration of the most
recent proven restore.
Findings go to the database owner with dates. Anything touching durability — an unproven restore, a failing archive, an unbounded slot — goes to the service owner on the same day, because those are commitments somebody outside the team is relying on.
Sign-off
- Reviewer: ________________ Date: ___________
- Database owner: ___________ Date: ___________
- Service owner: ____________ Date: ___________
Every critical item must pass. A failing critical item is a blocker, not a note for the next sprint: record the date, the reviewer, the disposition of every item that did not pass, and the name of whoever accepted the residual risk.