Re: recovery.signal not being removed when recovery complete

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: recovery.signal not being removed when recovery complete
Дата
Msg-id Zg31i-f58Y3SOiqE@paquier.xyz
обсуждение исходный текст
Ответ на recovery.signal not being removed when recovery complete  (Isaac Morland <isaac.morland@gmail.com>)
Список pgsql-general
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

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: could not open file "global/pg_filenode.map": Operation not permitted
Следующее
От: yudhi s
Дата:
Сообщение: Re: Moving delta data faster