On Fri, Aug 01, 2025 at 03:30:17PM +0530, Amit Kapila wrote:
> I mean to say we can use the same change LSN both for
> REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM and
> REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT. Right now, for
> REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM, we switch the change to
> specinsert which would have a prior LSN value (say, if confirm/abort
> record will have value, 1000, it will be 800 or so) but we should
> still use 1000 for update_progress_txn. The update_progress_txn() is
> helpful when such an insert is skipped by a plugin (in this case
> pgouput) and in that case, we would require the latest LSN processed
> by reorder buffer to pass to it. We use it to send a keep_alive to a
> client with the last LSN processed.
Ah, OK, I've missed your point then. It's kind of an optimization in
itself because we would be a bit more aggressive with the updates, but
I agree to do that in the scope of this fix. The updated attached
uses prev_lsn for the job, for both the ABORT and CONFIRM cases,
meaning a one-liner.
--
Michael