Re: standby promotion can create unreadable WAL
От | Robert Haas |
---|---|
Тема | Re: standby promotion can create unreadable WAL |
Дата | |
Msg-id | CA+TgmoaOJz-QJtzS0H9oNiV8kSRGM4P5sHPp+hnJRnqEaKnttQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: standby promotion can create unreadable WAL (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: standby promotion can create unreadable WAL
Re: standby promotion can create unreadable WAL |
Список | pgsql-hackers |
On Fri, Aug 26, 2022 at 8:44 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > ArchiveRecoveryRequested is true. So in the below check[1] instead of > (!StandbyMode), we can just put (! ArchiveRecoveryRequested), and then > we don't need any other fix. Am I missing anything? > > [1] > ReadRecord{ > ..record = XLogPrefetcherReadRecord(xlogprefetcher, &errormsg); > if (record == NULL) > { > /* > * When not in standby mode we find that WAL ends in an incomplete > * record, keep track of that record. After recovery is done, > * we’ll write a record to indicate to downstream WAL readers that > * that portion is to be ignored. > */ > if (!StandbyMode && > !XLogRecPtrIsInvalid(xlogreader->abortedRecPtr)) > { > abortedRecPtr = xlogreader->abortedRecPtr; > missingContrecPtr = xlogreader->missingContrecPtr; > } I agree. Testing StandbyMode here seems bogus. I thought initially that the test should perhaps be for InArchiveRecovery rather than ArchiveRecoveryRequested, but I see that the code which switches to a new timeline cares about ArchiveRecoveryRequested, so I think that is the correct thing to test here as well. Concretely, I propose the following patch. -- Robert Haas EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: