recovery.signal not being removed when recovery complete
I use a script to restore a backup to create a testing copy of the
database. I set the following in postgresql.auto.conf:
recovery_target = 'immediate'
recovery_target_action = 'promote'
In the logs I get "recovery stopping after reaching consistency" then a
moment later "database system is ready to accept read-only connections",
then some entries about restoring log files, then "database system is ready
to accept connections".
I am able to make changes (e.g. CREATE TABLE), yet recovery.signal is still
present. My understanding is that recovery.signal should be removed when
recovery is finished (i.e., more or less when "database system is ready to
accept connections" is logged?), unless recovery_target_action is set to
'shutdown'.
Any ideas? Even just confirming/denying I understand the above correctly
would help.
On Tue, Mar 26, 2024 at 06:22:32PM -0400, Isaac Morland wrote:
I use a script to restore a backup to create a testing copy of the
database. I set the following in postgresql.auto.conf:recovery_target = 'immediate'
recovery_target_action = 'promote'
Why not, after a pg_basebackup -R I assume. Would you mind sharing
your commands?
In the logs I get "recovery stopping after reaching consistency" then a
moment later "database system is ready to accept read-only connections",
then some entries about restoring log files, then "database system is ready
to accept connections".
If you have some logs, that could help as well.
I am able to make changes (e.g. CREATE TABLE), yet recovery.signal is still
present. My understanding is that recovery.signal should be removed when
recovery is finished (i.e., more or less when "database system is ready to
accept connections" is logged?), unless recovery_target_action is set to
'shutdown'.Any ideas? Even just confirming/denying I understand the above correctly
would help.
Not removing the two .signal files when promotion is achieved would be
a problem to me because we'd reenter recovery again at a follow-up
startup. ArchiveRecoveryRequested should be set if there was either
recovery.signal or standby.signal found at startup, meaning that we
should have a TLI jump at promotion with a physical removal of both
files and a LOG for a "selected new timeline ID".
--
Michael