Обсуждение: recovery.signal not being removed when recovery complete

Поиск
Список
Период
Сортировка

recovery.signal not being removed when recovery complete

От
Isaac Morland
Дата:
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.

Re: recovery.signal not being removed when recovery complete

От
Michael Paquier
Дата:
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

Вложения