pg_dump captures a consistent snapshot

Fri, 14 Jan 2028 00:00:00 +0000

pg_dump exports one PostgreSQL database using a consistent view of transactional data, even while other sessions commit changes. This prevents the ordinary table-by-table copy problem in which related tables reflect different committed states. The snapshot is only part of the backup contract: the archive must also be complete for its intended scope, readable by compatible tools, and successfully restored into a usable database.

Know what the snapshot covers

Rows visible to the dump’s snapshot remain its view throughout the export. Later commits do not gradually enter the dump just because one table is read after another. Parallel dumps synchronize workers’ snapshots rather than independently observing each table. They require directory format; custom format supports parallel restoration, but not parallel dumping.

A database snapshot does not make every business workflow atomic. If an application commits a batch header and its detail rows in separate transactions, a consistent snapshot can legitimately fall between those commits. Sequence state is also not ordinary MVCC row data, and external files or services are outside the database snapshot. Define the recovery invariant around actual transaction boundaries and all required data stores.

Account for load and dependencies

Dumping normally allows ordinary readers and writers to continue, but it still takes ACCESS SHARE locks and consumes CPU, I/O, connections, and snapshot lifetime. Conflicting schema changes can wait or make the dump fail. Long snapshots can prevent cleanup of old row versions. Parallel workers increase load; they do not make backup overhead disappear.

A standby can offload some reads, but recovery conflicts and lag need consideration, and unlogged table contents are excluded when dumping from a standby. One pg_dump does not include cluster-wide roles and tablespaces. Extensions, ownership, permissions, collation behavior, and target configuration must be included in the restore plan through their appropriate mechanisms. Splitting an export into unrelated table dumps can lose the common snapshot and dependency closure.

When it breaks

An archive listing can look healthy while restoration fails on a missing role or extension. Restore into an empty, isolated target with explicit error handling, then validate application invariants and representative queries. pg_restore normally continues after SQL errors and reports an error count; checking only the last printed query is inadequate. A single-transaction restore can provide atomicity for a small rehearsal, but cannot be combined with parallel jobs.

Tool versions are another boundary. A pg_dump client refuses a server newer than its own major version. Output is intended for the same or newer target versions; loading it into an older major version is not guaranteed. Verify the actual client, source, target, extensions, and restore options rather than relying on the generic claim that “Postgres backups are portable.”

Logical exports can meet an explicitly measured recovery objective, but they do not provide arbitrary point-in-time replay between dumps. Physical base backups plus a complete retained WAL chain serve that requirement. The acceptable interval follows the required data-loss window and restore time, not a universal rule that anything shorter than a day requires one specific schedule.

Check it quickly

Save the Bash block as dump.sh. It creates its own PostgreSQL cluster and removes it on exit. Run it with PostgreSQL 18 tools as a non-root user, or use this isolated container with no published port or host-data mount:

docker run --rm --network none --user postgres --entrypoint bash -i \
 postgres:18-alpine < dump.sh

#!/usr/bin/env bash
set -euo pipefail
dump_lab=$(mktemp -d /tmp/pgdump-lab.XXXXXX)
cleanup() {
 if [ -f "$dump_lab/data/postmaster.pid" ]; then
 pg_ctl -D "$dump_lab/data" -m fast -w stop >/dev/null
 fi
 rm -rf -- "$dump_lab"
}
trap cleanup EXIT
initdb -D "$dump_lab/data" --no-locale --encoding=UTF8 --auth=trust >/dev/null
pg_ctl -D "$dump_lab/data" -l "$dump_lab/server.log" \
 -o "-k $dump_lab -p 55432 -c listen_addresses=''" -w start >/dev/null
export PGHOST="$dump_lab" PGPORT=55432 PGDATABASE=source_db
export DUMP_FILE="$dump_lab/source.dump" DUMP_OK="$dump_lab/dump-ok"
createdb source_db
createdb restored_db
psql -X -v ON_ERROR_STOP=1 <<'SQL'
CREATE TABLE customers (id integer PRIMARY KEY, name text);
CREATE TABLE orders (id integer PRIMARY KEY, customer_id integer REFERENCES customers(id));
INSERT INTO customers VALUES (1,'before');
INSERT INTO orders VALUES (10,1);
BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;
SELECT pg_export_snapshot() AS snapshot_id \gset
\setenv DUMP_SNAPSHOT :snapshot_id
\! psql -X -v ON_ERROR_STOP=1 -c "BEGIN; INSERT INTO customers VALUES (2,'after'); INSERT INTO orders VALUES (20,2); COMMIT;" && pg_dump --format=custom --snapshot="$DUMP_SNAPSHOT" --file="$DUMP_FILE" && touch "$DUMP_OK"
COMMIT;
SQL
test -f "$DUMP_OK"
pg_restore --list "$DUMP_FILE" > "$dump_lab/archive-list"
pg_restore --exit-on-error --single-transaction --dbname=restored_db "$DUMP_FILE"
counts='SELECT (SELECT count(*) FROM customers), (SELECT count(*) FROM orders)'
test "$(psql -X -Atc "$counts")" = '2|2'
test "$(psql -X -d restored_db -Atc "$counts")" = '1|1'
test "$(psql -X -d restored_db -Atc 'SELECT count(*) FROM orders o LEFT JOIN customers c ON c.id=o.customer_id WHERE c.id IS NULL')" = 0
psql -X -d restored_db -v ON_ERROR_STOP=1 -c \
 'SELECT c.name,o.id FROM customers c JOIN orders o ON o.customer_id=c.id'
pg_dump --version
printf 'PASS: source=2|2 restored=1|1 orphan_orders=0\n'

The first session exports a snapshot containing one customer and one order. While that transaction remains open, a second session commits another related pair. The dump explicitly imports the earlier snapshot; restoration therefore produces 1|1, while the live source reports 2|2. The join returns customer “before” with order ten, and an orphan check returns zero.

On PostgreSQL 18.6, the complete restore and all assertions pass. The success marker ensures a failed nested shell dump cannot masquerade as success merely because psql continued. This demonstrates snapshot selection and restoration for the fixture, not a measured recovery time for the real application. Keep actual restore rehearsals, artifact checksums, retention, and dependency records with the production backup procedure.

Sources