Review dependencies before a selective PostgreSQL archive restore

Review the archive selection and required objects before recovering a PostgreSQL table subset.

Source facts

PostgreSQL 17 pg_restore can list archive contents and use an edited list to select and order restored items. Its table-selection option does not automatically restore every object on which a chosen table depends, so restoring one table into an empty database can fail. It also differs from pg_dump table selection: pg_restore does not support wildcard matching there or include subsidiary objects such as indexes merely because a table was selected. Selection requires a dependency decision.

Source: PostgreSQL 17 — pg_restore.

Applicability

This applies to PostgreSQL 17 archive-format logical backups processed by pg_restore. It addresses partial recovery planning, not permission to overwrite a live application’s tables.

DSE recommendation

DSE recommends first restoring the intended subset into a temporary database, retaining the reviewed table-of-contents list as part of the recovery request. Identify required schemas, types, sequences, functions, and indexes before moving any recovered data into the target service. Ask the application owner to define whether the goal is extracting missing records or replacing an object. Keep that decision explicit so a small recovery request does not silently become a destructive production restore.

Verification

Inspect the archive list, perform the selected restore in isolation, and review every warning. Check row relationships and required indexes with the application owner. Retain the final selection list and the method used to transfer approved recovered data, including any objects intentionally left out.

Official reference

PostgreSQL 17 — pg_restore. Reviewed October 15, 2026.