Comparing changes

heap_page_prune_and_freeze() had accumulated an unwieldy number of input parameters, and upcoming work to handle VM updates in this function will add even more. Introduce a new PruneFreezeParams struct to group the function’s input parameters, improving readability and maintainability. Discussion: https://postgr.es/m/yn4zp35kkdsjx6wf47zcfmxgexxt4h2og47pvnw2x5ifyrs3qc%407uw6jyyxuyf7

Previously, we relied on all_visible and all_frozen being used together to ensure that all_frozen was correct, but it is better to keep both fields updated. Future changes will separate their usage, so we should not depend on all_visible for the validity of all_frozen.

In the prune/freeze path, we currently delay clearing all_visible and all_frozen in the presence of dead items. This allows opportunistic freezing if the page would otherwise be fully frozen, since those dead items are later removed in vacuum’s third phase. To move the VM update into the same WAL record that prunes and freezes tuples, we must know whether the page will be marked all-visible/all-frozen before emitting WAL. The only barrier to updating these flags immediately after deciding whether to opportunistically freeze is that we previously used all_frozen to compute the snapshot conflict horizon when freezing tuples. By determining the cutoff earlier, we can update the flags immediately after making the freeze decision. This is required to set the VM in the XLOG_HEAP2_PRUNE_VACUUM_SCAN record emitted by pruning and freezing.

Vacuum no longer emits a separate WAL record for each page set all-visible or all-frozen during phase I. Instead, visibility map updates are now included in the XLOG_HEAP2_PRUNE_VACUUM_SCAN record that is already emitted for pruning and freezing. Previously, heap_page_prune_and_freeze() determined whether a page was all-visible, but the corresponding VM bits were only set later in lazy_scan_prune(). Now the VM is updated immediately in heap_page_prune_and_freeze(), at the same time as the heap modifications. This change applies only to vacuum phase I, not to pruning performed during normal page access. Reviewed-by: Robert Haas <[email protected]>

As part of removing XLOG_HEAP2_VISIBLE records, phase I of VACUUM now marks empty pages all-visible in a XLOG_HEAP2_PRUNE_VACUUM_SCAN record. Author: Melanie Plageman <[email protected]> Reviewed-by: Robert Haas <[email protected]>

As no remaining users emit XLOG_HEAP2_VISIBLE records. This includes deleting the xl_heap_visible struct and all functions responsible for emitting or replaying XLOG_HEAP2_VISIBLE records. Author: Melanie Plageman <[email protected]> Reviewed-by: Andrey Borodin <[email protected]>

The function is currently only used to check whether a tuple’s xmax is visible to all transactions (and thus removable). Upcoming changes will also use it to test whether a tuple’s xmin is visible to all to decide if a page can be marked all-visible in the visibility map. The new name, GlobalVisXidVisibleToAll(), better reflects this broader purpose. Reviewed-by: Kirill Reshke <[email protected]>

During vacuum's first and third phases, we examine tuples' visibility to determine if we can set the page all-visible in the visibility map. Previously, this check compared tuple xmins against a single XID chosen at the start of vacuum (OldestXmin). We now use GlobalVisState, which also enables future work to set the VM during on-access pruning, since ordinary queries have access to GlobalVisState but not OldestXmin. This also benefits vacuum directly: in some cases, GlobalVisState may advance during a vacuum, allowing more pages to become considered all-visible. And, in the future, we could easily add a heuristic to update GlobalVisState more frequently during vacuums of large tables. In the rare case that the GlobalVisState moves backward, vacuum falls back to OldestXmin to ensure we don’t attempt to freeze a dead tuple that wasn’t yet prunable according to the GlobalVisState. Because comparing a transaction ID against GlobalVisState is more expensive than comparing against a single XID, we defer this check until after scanning all tuples on the page. If visibility_cutoff_xid was maintained, we perform the GlobalVisState check only once per page. This is safe because visibility_cutoff_xid records the newest xmin on the page; if it is globally visible, then the entire page is all-visible. This approach may result in examining more tuple xmins than before, since with OldestXmin we could sometimes rule out the page being all-visible earlier. However, profiling shows the additional cost is not significant.

In the prune/freeze path, we currently delay clearing all_visible and all_frozen in the presence of dead items to allow opportunistic freezing. However, if no freezing will be attempted, there’s no need to delay. Clearing the flags earlier avoids extra bookkeeping in heap_prune_record_unchanged_lp_normal(). This currently has no runtime effect because all callers that consider setting the VM also prepare freeze plans, but upcoming changes will allow on-access pruning to set the VM without freezing. The extra bookkeeping was noticeable in a profile of on-access VM setting.

Many queries do not modify the underlying relation. For such queries, if on-access pruning occurs during the scan, we can check whether the page has become all-visible and update the visibility map accordingly. Previously, only vacuum and COPY FREEZE marked pages as all-visible or all-frozen. Supporting this requires passing information about whether the relation is modified from the executor down to the scan descriptor. This commit implements on-access VM setting for sequential scans as well as for the underlying heap relation in index scans and bitmap heap scans.

Now that visibility map (VM) updates can occur during read-only queries, it makes sense to also set the page’s pd_prune_xid hint during inserts. This enables heap_page_prune_and_freeze() to run after a page is filled with newly inserted tuples the first time it is read. This change also addresses a long-standing note in heap_insert() and heap_multi_insert(), which observed that setting pd_prune_xid would help clean up aborted insertions sooner. Without it, such tuples might linger until VACUUM, whereas now they can be pruned earlier. Setting pd_prune_xid on insert can cause a page to be dirtied and written out when it previously would not have been, affetcting the reported number of hits in the index-killtuples isolation test. It is unclear if this is a bug in the way hits are tracked, a faulty test expectation, or if simply updating the test's expected output is sufficient remediation.

…REEZE WAL volume This branch was automatically generated by a robot using patches from an email thread registered at: https://commitfest.postgresql.org/patch/5841 The branch will be overwritten each time a new patch version is posted to the thread, and also periodically to check for bitrot caused by changes on the master branch. Patch(es): https://www.postgresql.org/message-id/CAAKRu_YR-COJ9aGnMUQqt5yoWmUBjikqrd4jGNZYouHaXpis9g@mail.gmail.com Author(s): Melanie Plageman

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Oct 14, 2025

This comparison is taking too long to generate.

Uh oh!