Re: recovery.signal not being removed when recovery complete

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