Fix xmin advancement during fast_forward decoding. During logical decoding, we advance catalog_xmin of logical too early in fast_forward mode, resulting in required catalog data being removed by vacuum. This mode is normally used to advance the slot without processing the changes, but we still can't let the slot's xmin to advance to an incorrect value.
Commit f49a80c481 fixed a similar issue where the logical slot's catalog_xmin was getting advanced prematurely during non-fast-forward mode. During xl_running_xacts processing, instead of directly advancing the slot's xmin to the oldest running xid in the record, it allowed the xmin to be held back for snapshots that can be used for not-yet-replayed transactions, as those might consider older txns as running too. However, it missed the fact that the same problem can happen during fast_forward mode decoding, as we won't build a base snapshot in that mode, and the future call to get_changes from the same slot can miss seeing the required catalog changes leading to incorrect reslts. This commit allows building the base snapshot even in fast_forward mode to prevent the early advancement of xmin. Reported-by: Amit Kapila <amit.kapil...@gmail.com> Author: Zhijie Hou <houzj.f...@fujitsu.com> Reviewed-by: Masahiko Sawada <sawada.m...@gmail.com> Reviewed-by: shveta malik <shveta.ma...@gmail.com> Reviewed-by: Amit Kapila <amit.kapil...@gmail.com> Backpatch-through: 13 Discussion: https://postgr.es/m/caa4ek1lqwncuoqkijiafe+ypt1gqaqrjctklmy953j79xdb...@mail.gmail.com Discussion: https://postgr.es/m/os0pr01mb57163087f86621d44d9a72bf94...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/aaf9e95e8764093ab55baf27c35705f406f592f9 Modified Files -------------- contrib/test_decoding/expected/oldest_xmin.out | 41 ++++++++++++++++++++++++++ contrib/test_decoding/specs/oldest_xmin.spec | 5 ++++ src/backend/replication/logical/decode.c | 37 +++++++++++++++-------- 3 files changed, 71 insertions(+), 12 deletions(-)
