Re: All-visible pages with valid prune xid are confusing

On Sat, Feb 28, 2026 at 1:55 PM Andres Freund <andres(at)anarazel(dot)de> 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