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