Re: Reorderbuffer crash during recovery
От | vignesh C |
---|---|
Тема | Re: Reorderbuffer crash during recovery |
Дата | |
Msg-id | CALDaNm2Xe5OK8MeSv_=1U7+p8-p3bA2qiWh8CbtmmmemYKGcyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reorderbuffer crash during recovery (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Reorderbuffer crash during recovery
Re: Reorderbuffer crash during recovery |
Список | pgsql-bugs |
On Tue, Dec 17, 2019 at 2:32 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Dec 11, 2019 at 11:13 AM vignesh C <vignesh21@gmail.com> wrote: > > > > > > It sets the final_lsn here so that it can iterate from the start_lsn > > to final_lsn and cleanup the serialized files in > > ReorderBufferRestoreCleanup function. One solution We were thinking > > was to store the lsn of the last serialized change while serialiizing > > and set the final_lsn in the above case where it crashes like the > > below code: > > Sure, we can do something on the lines what you are suggesting, but > why can't we update final_lsn at the time of serializing the changes? > If we do that then we don't even need to compute it separately during > ReorderBufferAbortOld. > > Let me try to explain the problem and proposed solutions for the same. > Currently, after serializing the changes we remove the 'changes' from > ReorderBufferTXN. Now, if the system crashes due to any reason after > that, we won't be able to compute final_lsn after the restart. And > that leads to access violation in ReorderBufferAbortOld which is > trying to access changes list from ReorderBufferTXN to compute > final_lsn. > > We could fix it by either tracking 'last_serialized_change' as > proposed by Vignesh or we could update the final_lsn while we > serialize the changes. > I felt amit solution also solves the problem. Attached patch has the fix based on the solution proposed. Thoughts? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: