Thread: 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'
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