On Tue, Feb 8, 2022 at 5:27 AM osumi.takami...@fujitsu.com <osumi.takami...@fujitsu.com> wrote: > > On Friday, August 13, 2021 8:01 PM Ajin Cherian <itsa...@gmail.com> wrote: > > On Mon, Aug 2, 2021 at 7:20 PM Amit Kapila <amit.kapil...@gmail.com> > > wrote: > Changing the timing to send the keepalive to the decoding commit > timing didn't look impossible to me, although my suggestion > can be ad-hoc. > > After the initialization of sentPtr(by confirmed_flush lsn), > sentPtr is updated from logical_decoding_ctx->reader->EndRecPtr in > XLogSendLogical. > In the XLogSendLogical, we update it after we execute > LogicalDecodingProcessRecord. > This order leads to the current implementation to wait the next iteration > to send a keepalive in WalSndWaitForWal. > > But, I felt we can utilize end_lsn passed to ReorderBufferCommit for updating > sentPtr. The end_lsn is the lsn same as the ctx->reader->EndRecPtr, > which means advancing the timing to update the sentPtr for the commit case. > Then if the transaction is empty in synchronous mode, > send the keepalive in WalSndUpdateProgress directly, > instead of having the force_keepalive_syncrep flag and having it true. >
You have a point in that we don't need to delay sending this message till next WalSndWaitForWal() but I don't see why we need to change anything about update of sentPtr. -- With Regards, Amit Kapila.
