Cloning PITR from backup: server did not start in time

[Marc Olivé]

Hello people,

We have PGO 5.0.4 running PG14, with S3 backups configured.

Yesterday we cloned the DB from the backup at a specific time, with PITR, for the first time, which ended up with the error:

2022-03-31 05:36:58.496 GMT [38] LOG:  starting PostgreSQL 14.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit

[..]

2022-03-31 05:37:57.204 GMT [39] LOG:  restored log file "0000000500000F9F00000089" from archive

2022-03-31 05:37:57.730 GMT [39] LOG:  restored log file "0000000500000F9F0000008A" from archive

2022-03-31 05:37:58.132 GMT [39] LOG:  restored log file "0000000500000F9F0000008B" from archive

pg_ctl: server did not start in time

This was because "pg_ctl" has a timeout of one minute, it started at 05:36:58 and stopped at  05:37:58.

We ended up having the clone up and running with some manual intervention, but we would like to have it fully automated.

There's the environment variable "PGCTLTIMEOUT" we can tune, but we don't know which is the best place to setup it. In the docker directory "bin/postgres_common/postgres/" are the files "setenv.sh" and "pgbackrest_env.sh", which seems the place to set the "PGCTLTIMEOUT".

Shall we add "export PGCTLTIMEOUT=600" on "pgbackrest_env.sh" and it will do the trick on restoring/cloning? Or is there a better place or solution?

Regards,

--

Marc Olivé

[Andrew L'Ecuyer]

Hi Marc,

Thanks for reaching out regarding your restore issue.

I just wanted to let you know that we are tracking a fix for this issue in our backlog, and plan to provide a way to allow the PGCTLTIMEOUT setting to be configured in an upcoming PGO release.

Thanks!

Andrew

[Marc Olivé]

Good to know Adrew!

Good job, thanks

--

Marc Olivé

--
You received this message because you are subscribed to the Google Groups "Postgres Operator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to postgres-opera...@crunchydata.com.