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 | 20200420142235.1536a73b@firost обсуждение исходный текст |
Ответ на | Re: [BUG] non archived WAL removed during production crash recovery (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [BUG] non archived WAL removed during production crash recovery
|
Список | pgsql-bugs |
On Mon, 20 Apr 2020 16:34:44 +0900 Michael Paquier <michael@paquier.xyz> wrote: [...] > > By the way I noticed that RecoveryState is exactly a subset of > > DBState. And changes of SharedRecoveryState happens side-by-side with > > ControlFileData->state in most places. Coundn't we just usee > > ControlFile->state instead of SharedRecoveryState? > > I actually found confusing to use the same thing, because then the > reader would thing that SharedRecoveryState could be set to more > values but we don't want that. I thought about this while studying various possible fix. https://www.postgresql.org/message-id/flat/20200401181735.11100908%40firost#6192afba4e4549b8d9bac03168bad46b The problem is that we would have to read the controldata file each time we wonder if a segment should be archived/removed. Moreover, the controldata file might not be in sync quickly enough with the real state for some other code path or futur needs. [...] > Attached is an updated patch, where I tweaked more comments. > > Jehan-Guillaume, who is your colleague who found originally about this > problem? We should credit him in the commit message. Indeed, Benoît Lobréau reported this behavior to me. Regards,
В списке pgsql-bugs по дате отправления: