Hello! On Thu, Nov 27, 2025 at 9:07 PM Matthias van de Meent <[email protected]> wrote: > While it might not break, and might not hold back other tables' > visibility horizons, it'll still hold back pruning on the table we're > acting on, and that's likely one which already had bloat issues if > you're running RIC (or REPACK).
Yes, a good point about REPACK, agreed. BTW, what is about using the same reset snapshot technique for REPACK also? I thought it is impossible, but what if we: * while reading the heap we "remember" our current page position into shared memory * preserve all xmin/max/cid into newly created repacked table (we need it for MVCC-safe approach anyway) * in logical decoding layer - we check TID of our tuple and looking at "current page" we may correctly decide what to do with at apply phase: - if it in "non-yet read pages" - ignore (we will read it later) - but signal scan to ensure it will reset snapshot before that page (reset_before = min(reset_before, tid)) - if it in "already read pages" - remember the apply operation (with exact target xmin/xmax and resulting xmin/xmax) Before switching table - use the same "limit_xmin" logic to wait for other transactions the same way CIC does. It may involve some tricky locking, maybe I missed some cases, but it feels like it is possible to do it correctly by combining information of scan state and xmin/xmax/tid/etc... PS. > PS. When I checked the code you linked to on that thread, I noticed > there is a stale pointer dereference issue in > GetPinnedOldestNonRemovableTransactionId, where it pulls data from a > hash table entry that could've been released by that point. Thanks!
