Re: using an end-of-recovery record in all cases
От | Robert Haas |
---|---|
Тема | Re: using an end-of-recovery record in all cases |
Дата | |
Msg-id | CA+Tgmob10roZ8K2A0e11782Vc+TveN5anPrS6R0j8fZixppJsg@mail.gmail.com обсуждение исходный текст |
Ответ на | using an end-of-recovery record in all cases (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: using an end-of-recovery record in all cases
|
Список | pgsql-hackers |
On Mon, Aug 9, 2021 at 3:00 PM Robert Haas <robertmhaas@gmail.com> wrote: > I decided to try writing a patch to use an end-of-recovery record > rather than a checkpoint record in all cases. > > The first problem I hit was that GetRunningTransactionData() does > Assert(TransactionIdIsNormal(CurrentRunningXacts->latestCompletedXid)). > > Unfortunately we can't just relax the assertion, because the > XLOG_RUNNING_XACTS record will eventually be handed to > ProcArrayApplyRecoveryInfo() for processing ... and that function > contains a matching assertion which would in turn fail. It in turn > passes the value to MaintainLatestCompletedXidRecovery() which > contains yet another matching assertion, so the restriction to normal > XIDs here looks pretty deliberate. There are no comments, though, so > the reader is left to guess why. I see one problem: > MaintainLatestCompletedXidRecovery uses FullXidRelativeTo, which > expects a normal XID. Perhaps it's best to just dodge the entire issue > by skipping LogStandbySnapshot() if latestCompletedXid happens to be > 2, but that feels like a hack, because AFAICS the real problem is that > StartupXLog() doesn't agree with the rest of the code on whether 2 is > a legal case, and maybe we ought to be storing a value that doesn't > need to be computed via TransactionIdRetreat(). Anyone have any thoughts about this? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: