Re: Reorderbuffer crash during recovery
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-01-17T03:13:28Z
Lists: pgsql-bugs, pgsql-hackers
On Fri, Jan 17, 2020 at 7:42 AM vignesh C <vignesh21@gmail.com> wrote: > > On Thu, Jan 16, 2020 at 9:17 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > One minor comment. Otherwise, the patch looks fine to me. > > + /* > > + * We set final_lsn on a transaction when we decode its commit or abort > > + * record, but we never see those records for crashed transactions. To > > + * ensure cleanup of these transactions, set final_lsn to that of their > > + * last change; this causes ReorderBufferRestoreCleanup to do the right > > + * thing. Final_lsn would have been set with commit_lsn earlier when we > > + * decode it commit, no need to update in that case > > + */ > > + if (txn->final_lsn < change->lsn) > > + txn->final_lsn = change->lsn; > > > > /decode it commit,/decode its commit, > > > > Thanks Dilip for reviewing. > I have fixed the comments you have suggested. > Thanks for the updated patch. It looks fine to me. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Set ReorderBufferTXN->final_lsn more eagerly
- fe955ebee0f2 11.7 landed
- e3154aae3c26 10.12 landed
- cdb14154bb00 9.6.17 landed
- bc2140627ff1 12.2 landed
- 58997ace5b37 9.5.21 landed
- 20a1dc1e311d 9.4.26 landed
- 15cac3a523cc 13.0 landed
-
Fix failure to delete spill files of aborted transactions
- df9f682c7bf8 11.0 cited