On Sat, Feb 28, 2026 at 1:55 PM Andres Freund <[email protected]> wrote: > > On 2026-02-27 18:56:48 -0500, Melanie Plageman wrote: > > > Regarding Andres' idea to include pd_prune_xid to the xl_heap_prune > > WAL record: I don't feel quite comfortable that pd_prune_xid would > > then be half WAL-logged (since it isn't logged when update/delete sets > > it). Maybe it's fine, though. > > What do you mean with half WAL logged? Just that PageSetPrunable() will take > the current pd_prune_xid into account, which could differ on the standby? > We'd still not put in an XID that wasn't in a WAL record, right?
Yes, I guess since the xl_xid is from the primary and the standby uses that to compare to the current pd_prune_xid, they'll only be different if the standby's pd_prune_xid is different. > I think the case of xl_heap_prune is markedly different from e.g. the delete > case, because the choice of the xid to use for pd_prune_xid is a lot more > complicated in the other cases. Without inspecting all the surviving rows, the > standby just don't have a sane value to put into pd_prune_xid. Whereas for a > delete, update, insert we know that it's just the smaller of the current > pd_prune_xid and the xid of the record. I think adding pd_prune_xid to xl_heap_prune is a worthwhile addition on top of this commit since this commit also clears pd_prune_xid in a few other cases. > What about the PageSetAllVisible() in lazy_scan_prune()? I know that code > will vanish soon, but still... Good point. I think my LSP plugin got confused switching back and forth between this branch and the one where I remove that code and missed the reference. Fixed in the pushed version. Thanks for the review! - Melanie
