On Tue, Apr 22, 2025 at 12:36 PM Zhijie Hou (Fujitsu) <houzj.f...@fujitsu.com> wrote: > > Hi, > > To fix this, I think we can allow the base snapshot to be built during fast > forward decoding, as implemented in the patch 0001 (We already built base > snapshot in fast-forward mode for logical message in logicalmsg_decode()).
The idea and code looks okay to me and the performance impact is also not that huge. IIUC, fast_forward decoding mode is used only in two cases. 1) pg_replication_slot_advance and 2) in upgrade flow to check if there are any pending WAL changes which are not yet replicated. See 'binary_upgrade_logical_slot_has_caught_up'-->'LogicalReplicationSlotHasPendingWal'. It seems like this change will not have any negative impact in the upgrade flow as well (in terms of performance and anything else). Thoughts? > > Moreover, I conducted a basic test[2] to test the patch's impact, noting that > advancing the slot incurs roughly a 4% increase in processing time after > applying the patch, which appears to be acceptable. Additionally, the cost > associated with building the snapshot via SnapBuildBuildSnapshot() did not > show > up in the profile. Therefore, I think it's reasonable to refrain from > further optimization at this stage. I agree on this. thanks Shveta
