On Wed, Dec 11, 2024 at 3:18 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Mon, Dec 9, 2024 at 10:19 PM Dilip Kumar <dilipbal...@gmail.com> wrote:
> > > > > > If the largest transaction is non-streamable, won't the transaction > > > returned by ReorderBufferLargestTXN() in the other case already > > > suffice the need? > > > > I see your point, but I don’t think it’s quite the same. When > > ReorderBufferCanStartStreaming() is true, the function > > ReorderBufferLargestStreamableTopTXN() looks for the largest > > transaction among those that have a base_snapshot. So, if the largest > > transaction is aborted but hasn’t yet received a base_snapshot, it > > will instead select the largest transaction that does have a > > base_snapshot, which could be significantly smaller than the largest > > aborted transaction. > > IIUC the transaction entries in reorderbuffer have the base snapshot > before decoding the first change (see SnapBuildProcessChange()). In > which case the transaction doesn't have the base snapshot and has the > largest amount of changes? Subtransaction entries could transfer its > base snapshot to its parent transaction entry but such subtransactions > will be picked by ReorderBufferLargestTXN(). > IIRC, there could be cases where reorder buffers of transactions can grow in size without having a base snapshot, I think transactions doing DDLs and generating a lot of INVALIDATION messages could fall in such a category. And that was one of the reasons why we were using txns_by_base_snapshot_lsn inside ReorderBufferLargestStreamableTopTXN(). -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
