Re: [BUG] non archived WAL removed during production crash recovery
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | Re: [BUG] non archived WAL removed during production crash recovery |
Дата | |
Msg-id | 20200402150234.278ae845@firost обсуждение исходный текст |
Ответ на | Re: [BUG] non archived WAL removed during production crash recovery (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: [BUG] non archived WAL removed during production crash recovery
|
Список | pgsql-bugs |
On Thu, 02 Apr 2020 13:07:34 +0900 (JST) Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > Sorry, it was quite ambiguous. > > At Thu, 02 Apr 2020 13:04:43 +0900 (JST), Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote in > > At Wed, 1 Apr 2020 18:17:35 +0200, Jehan-Guillaume de Rorthais > > <jgdr@dalibo.com> wrote in > > > Please, find in attachment a patch implementing this. > > > > The patch partially reintroduces the issue the patch have > > fixed. Specifically a standby running a crash recovery wrongly marks a > > WAL file as ".ready" if it is extant in pg_wal without accompanied by > > .ready file. > > The patch partially reintroduces the issue the commit 78ea8b5daa have > fixed. Specifically a standby running a crash recovery wrongly marks a > WAL file as ".ready" if it is extant in pg_wal without accompanied by > .ready file. As far as I understand StartupXLOG(), NOT_IN_RECOVERY and IN_CRASH_RECOVERY are only set for production clusters, not standby ones. So the following test should never catch standby cluster as : (XLogArchivingActive() && inRecoveryState != IN_ARCHIVE_RECOVERY) Forgive me if I'm wrong, but do I miss something? Regards,
В списке pgsql-bugs по дате отправления: