fix(db): seed postgresql-custom idempotently instead of empty-dir check

[ymichaelson]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

The init-pgsodium container copies default /etc/postgresql-custom config
files only when the pgsodium volume is empty ([ -z "$(ls -A)" ]). On
block-storage volumes (OpenEBS LVM, AWS EBS, GCE PD, Ceph RBD, ...) the
ext4/xfs filesystem ships a lost+found directory, so the volume is never
truly empty on first use. The copy is skipped, the config files are missing,
and postgres fails to start:

FATAL: configuration file "/etc/postgresql/postgresql.conf" contains errors
could not open configuration file "/etc/postgresql-custom/wal-g.conf": No such file or directory

Result: db StatefulSet in CrashLoopBackOff on any block-backed StorageClass.

Fixes #248.

What is the new behavior?

Replace the emptiness check with an idempotent, no-clobber copy:

cp -an /etc/postgresql-custom/. /mnt/pgsodium/ 2>/dev/null || true

• -n (no-clobber) never overwrites existing files, so runtime-generated
  pgsodium keys are preserved across restarts (the reason feat(db): add persistent pgsodium volume mounted at /etc/postgresql-custom #197 added the
  persistent volume).
• Missing config files are seeded on every start, so a pre-existing
  lost+found no longer blocks the copy.
• Works the same on emptyDir and block-backed volumes.

Additional context

Verified cp -an idempotency locally: a runtime-modified file is preserved,
a missing file is re-seeded, and a lost+found directory has no effect.
helm lint passes and templates render. Chart version bumped 0.7.2 -> 0.7.3.

[luizfelmach]

Hi @ymichaelson, thanks for the PR. The idea of replacing the empty-dir check with an idempotent copy is definitely the right direction for block-storage volumes.

I wanted to let you know that the test / test (pull_request) CI check is currently failing after ~6 minutes. The chart-testing install step fails because the db StatefulSet ends up in CrashLoopBackOff.

I reproduced it locally and the root cause is that cp -an behaves differently (and silently skips the copy) in BusyBox, which is what the supabase/postgres image uses:

$ docker run --rm --entrypoint /bin/sh supabase/postgres:17.6.1.136 -c 'cp --version'
cp: unrecognized option: version
BusyBox v1.37.0

$ docker run --rm -v vol:/mnt/pgsodium supabase/postgres:17.6.1.136 -c 'cp -an /etc/postgresql-custom/. /mnt/pgsodium/ && ls /mnt/pgsodium'
# exit 0, but nothing is copied

So the init-pgsodium container finishes successfully but leaves /mnt/pgsodium empty. Then the postgres container mounts that empty volume at /etc/postgresql-custom and fails with:

could not open configuration file "/etc/postgresql-custom/wal-g.conf": No such file or directory
FATAL: configuration file "/etc/postgresql/postgresql.conf" contains errors