RE: Fix premature xmin advancement during fast forward decoding
Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
From: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2025-04-23T08:20:53Z
Lists: pgsql-hackers
On Wed, Apr 23, 2025 at 2:31 PM shveta malik wrote: > > On Tue, Apr 22, 2025 at 12:36 PM Zhijie Hou (Fujitsu) > <houzj.fnst@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. Thanks for reviewing! > > 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'-->'LogicalReplicationSlotHasP > endingWal'. > 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? I also think so. The upgrade uses fast forward decoding to check if there are any pending WALs not sent yet and report an ERROR if so. This indicates that we do not expect to decode real changes for the upgrade slots, so the performance impact would be minimal in normal cases. Best Regards, Hou zj
Commits
-
Fix xmin advancement during fast_forward decoding.
- d65485b02b1f 13.21 landed
- aaf9e95e8764 18.0 landed
- 36148b22ee09 17.5 landed
- 21a7caeeb948 16.9 landed
- f6429bd7db5e 15.13 landed
- 1f63b3626a52 14.18 landed
-
Fix "base" snapshot handling in logical decoding
- f49a80c481f7 11.0 cited