On Mon, Nov 14, 2022 at 9:38 AM Andres Freund <and...@anarazel.de> wrote: > Anyway, I played a bit around with this. It's hard to hit, not because we > somehow won't choose such a horizon, but because we'll commonly prune the > earlier tuple version away due to xmax being old enough.
That must be a bug, then. Since, as I said, I can't see how it could possibly be okay to freeze an xmin of tuple in a HOT chain without also making sure that it has no earlier versions left behind. If there are earlier versions that we have to go through to get to the frozen-xmin tuple (not just an LP_REDIRECT), we're going to break the HOT chain traversal logic in code like heap_hot_search_buffer in a rather obvious way. HOT chain traversal logic code will interpret the frozen xmin from the tuple as FrozenTransactionId (not as its raw xmin). So traversal is just broken in this scenario. > It *is* possible to > hit, if the horizon increases between the two tuple version checks (e.g. if > there's another tuple inbetween that we check the visibility of). I suppose that that's the detail that "protects" us, then -- that would explain the apparent lack of problems in the field. Your sequence requires 3 sessions, not just 2. -- Peter Geoghegan