When intentionally specifying a PITR target time that exceeds the available WAL archive on PostgreSQL 13+, does the playbook hang in the [recovery] stage for up to 24 hours before timing out?
#--------------------------------------------------------------#
PITR RECOVERY [recovery]
#--------------------------------------------------------------#
pgbackrest will restore the base data, while you'll need to
start postgres to restore them to the target location
When intentionally specifying a PITR target time that exceeds the available WAL archive on PostgreSQL 13+, does the playbook hang in the [recovery] stage for up to 24 hours before timing out?
#--------------------------------------------------------------#
PITR RECOVERY [recovery]
#--------------------------------------------------------------#
pgbackrest will restore the base data, while you'll need to
start postgres to restore them to the target location
name: start postgres recovery
tags: recovery
become_user: "{{ pg_dbsu|default('postgres') }}"
become: true
block:
name: start postgresql with /pg/tmp/recovery.log
shell: |
"{{ pg_bin_dir|default('/usr/pgsql/bin') }}/pg_ctl" -W -D {{ pg_data }} -o "-c port={{ pg_port }} -c logging_collector=on -c log_destination=stderr -c log_directory=/pg/tmp -c log_filename=recovery.log" start
name: wait for wal replay to recovery target
tags: recovery
wait_for:
path: /pg/tmp/recovery.log
search_regex: "consistent recovery state reached"
timeout: 86400
delay: 5