restore.sh: take the standby parameter settings from pg_control

[souravbiswassanto]

A PITR restore replays WAL, which makes the recovery instance a standby. PostgreSQL then enforces that max_connections, max_worker_processes, max_locks_per_transaction and max_prepared_transactions are each >= the value recorded in the source’s pg_control.

On a KubeDB database those are normally raised through the config secret. That secret is mounted at /etc/config in the database pod, but the WAL-restore sidekick gets no such mount — getRestoreSidekickVolumes in postgres/pkg/controller/sidekick.go builds only the data PVC plus the three script volumes. So the role template’s include_if_exists = '/etc/config/user.conf' resolves to nothing and recovery falls back to the built-in defaults 100 / 8 / 64 / 0.

Against any database whose configuration raises them, replay dies immediately and keeps retrying:

FATAL:  recovery aborted because of insufficient parameter settings
DETAIL: max_connections = 100 is a lower setting than on the primary server,
        where its value was 200.

Nothing surfaces this. The pods stay Running and the Postgres object sits in Provisioning; the only evidence is in kubectl logs <db>-wal-restorer-0.

Approach

Read the values out of the restored control file. pg_controldata is already in the image and reports exactly what the check compares against, so this needs no knowledge of how the source was configured.

Why not mount the config secret instead

I tried that first. It works for the parameter check but immediately fails differently:

FATAL: 58P01: could not access file "pg_stat_monitor": No such file or directory

The restore image is postgres-archiver:*_16.1-bookworm, a generic Debian Postgres — not the enterprise DB image. It cannot load the extensions a real deployment names in shared_preload_libraries. That is presumably why this script already pins shared_preload_libraries to a minimal list. Mounting the user config would undo that deliberate choice, so reading pg_control is the safer fix.

max_wal_senders is left alone unless the source ran with more than the 90 this script already pins.

Two details worth noting for review:

• The block is appended after the role template so nothing downstream can lower the values again.
• It starts with an explicit printf '\n' because the role template does not end with a newline. Without it the first setting is silently absorbed into the template’s trailing comment (# icu_validation_level = warningmax_connections = 200) — I hit exactly that during testing.

Verification

On a KubeDB cluster with a source running max_connections = 200, max_worker_processes = 24:

• Before: the restore stalled indefinitely and only completed after hand-appending the settings inside the restorer pod.
• After: the same restore completes unattended and lands exactly on the target.

	restored	source
total rows	3600	4200
rows written after the target	0	600
latest row	25s before the target	—
in_recovery	false	—
max_connections	200	200

Unrelated observation

echo "max_replication_slots = 90" >>/tmp/postgresql.conf on the line after mv /tmp/postgresql.conf "$PGDATA/postgresql.conf" writes to a file that has already been moved, so it is a no-op. Left untouched to keep this diff focused — flagging in case it is not intentional.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 9c9242ea-c7db-4176-94b0-e0e1505677df

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}