On Fri, May 23, 2025 at 12:04 PM Andres Freund <and...@anarazel.de> wrote: > > > 2) if our inclusion of a cutoff_xid when freezing tuples is what makes > > it safe to omit it from the VM update, then wouldn't that be true if > > we included a cutoff_xid when pruning a page in a way that rendered it > > all-visible too? > > I don't think omitting WAL for VM updates or whatnot is related to the > conflict horizon. That's really just for determining whether existing > snapshots on the standby conflict with the replay of the record.
What I was really trying to determine is how much the VM record is responsible for fast-forwarding the snapshot conflict horizon for this page. In my code which seeks to emit a single record for prune/freeze/vm update, I think I need the page visibility cutoff xid to be the snapshot conflict horizon when the record includes a VM update. > > For context, I'm writing a patch to add VM update redo to the > > xl_heap_prune record, and, in some cases, the record will only contain > > an update to the VM and I'm trying to determine when I need a snapshot > > conflict horizon in the record. > > You need to include it if the replay of the record might invalidate existing > snapshots. I can't immediately think of a case where that would happen without > more than just a VM update. Yes, I think this is true. In fact, if you are only updating the VM after pruning/freezing (i.e. making no other modifications to the heap page [including setting PD_ALL_VISIBLE]), I think the rule for a combined prune/freeze/vm record is: 1) if you are not updating the VM, current rules (in master) apply for calculating the snapshot conflict horizon 2) if you updating the VM and you are modifying the heap page at all -- either to prune, freeze, or set PD_ALL_VISIBLE -- then the combined record must have the visibility cutoff xid for the page as its snapshot conflict horizon 3) if you are updating the VM and you are not modifying the heap page at all, then you don't need to include a snapshot conflict horizon in the record because you can safely assume that a record with the visibility cutoff xid for that heap page as the snapshot conflict horizon has already been emitted. And any existing snapshots that would conflict with it would have conflicted with the previous record. I think 3 can only happen if something goes wrong with the VM -- like it is lost somehow. What I am wondering is if it is worth omitting the snapshot conflict horizon in the third case. Currently, you would emit an xl_heap_visible record with InvalidTransactionId as the conflict horizon in this case. But you aren't saving any space and it doesn't seem like you are saving any queries from being canceled by not doing this. It simply makes the logic for what to put in the WAL record more complicated. - Melanie
