pgrx incorrectly tries to initdb an existing data directory when running `test --runas`
While working on pgxn/docker-pgxn-tools#16, using the newly-released v0.11.4, I found that running cargo pgrx test --runas postgres --pgdata $dir a second time fails with this error:
Failed to initialize database using command: cd "/var/lib/postgresql/pgrx" && "sudo" "-u" "postgres" "/usr/lib/postgresql/16/bin/initdb" "--locale=C.UTF-8" "-D" "/var/lib/postgresql/pgrx/16"
It appears that on the second run pgrx, running as postgres, doesn't know the directory is already initialized. Easily worked around by deleting the directory after testing, but perhaps there's some sort of check that could let it work with an existing directory?
Replicate
git clone [email protected]:pgxn/docker-pgxn-tools.git
cd docker-pgxn-tools
docker build -t pgxn-tools .
cd $pgrx_project
docker run -it --rm -v "$PWD:/work" --entrypoint bash -w /work pgxn-tools
pg-start 16
cargo install --locked cargo-pgrx --version 0.11.4
cargo pgrx init --pg16=$(which pg_config)
cargo pgrx package --test --pg-config $(which pg_config)
cargo pgrx install --test --pg-config $(which pg_config)
cargo pgrx test --runas postgres --pgdata /var/lib/postgresql/pgrx pg16
cargo pgrx test --runas postgres --pgdata /var/lib/postgresql/pgrx pg16
I'm happy to accept a PR to fix this behavior but I'm not sure what would be the most coherent, since there's a lot of erroneous states that can arise from all this permission-switching and the way I see it any solution here is mostly picking which errors we most want to encounter and thus which ones we think people are most equipped to fix.
ISTM that it should not run initdb if the directory already exists and is initialized, but maybe should error out if it's owned by the wrong user.