On 2019-Dec-27, vignesh C wrote: > I felt amit solution also solves the problem. Attached patch has the > fix based on the solution proposed. > Thoughts?
This seems a sensible fix to me, though I didn't try to reproduce the failure. > @@ -2472,6 +2457,7 @@ ReorderBufferSerializeTXN(ReorderBuffer *rb, > ReorderBufferTXN *txn) > } > > ReorderBufferSerializeChange(rb, txn, fd, change); > + txn->final_lsn = change->lsn; > dlist_delete(&change->node); > ReorderBufferReturnChange(rb, change); Should this be done insider ReorderBufferSerializeChange itself, instead of in its caller? Also, would it be sane to verify that the TXN doesn't already have a newer final_lsn? Maybe as an Assert. > @@ -188,8 +188,7 @@ typedef struct ReorderBufferTXN > * * plain abort record > * * prepared transaction abort > * * error during decoding > - * * for a crashed transaction, the LSN of the last change, regardless > of > - * what it was. > + * * last serialized lsn > * ---- I propose "for a transaction with serialized changes, the LSN of the latest serialized one, unless one of the above cases." -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
