I Use This!
Very High Activity

Commits : Individual Commit

Analyzed about 13 hours ago. based on code collected about 13 hours ago.

Commit ID 65ec565b19fc35e9b09edcba4aecac350334ce87

Contributor: Melanie Plageman Files Modified 1
Date: 20-November-2025 at 16:40 Lines Added: 54
Repository: https://github.com/postgres/postgres master Lines Removed: 53
Commit Comment: Update PruneState.all_[visible|frozen] earlier in pruning During pruning and freezing in phase I of vacuum, we 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 phase III. 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. Previously we waited until after emitting WAL to update all_visible/all_frozen to their correct values. The only barrier to updating these flags immediately after deciding whether to opportunistically freeze was that while emitting WAL for a record freezing tuples, we use the pre-corrected value of all_frozen to compute the snapshot conflict horizon. By determining the conflict horizon earlier, we can update the flags immediately after making the opportunistic freeze decision. This is required to set the VM in the XLOG_HEAP2_PRUNE_VACUUM_SCAN record emitted by pruning and freezing. Author: Melanie Plageman <[email protected]> Reviewed-by: Kirill Reshke <[email protected]> Discussion: https://postgr.es/m/flat/CAAKRu_ZMw6Npd_qm2KM%2BFwQ3cMOMx1Dh3VMhp8-V7SOLxdK9-g%40mail.gmail.com

Changes by Language

Language Code Added Code Removed Comments Added Comments Removed Blanks Added Blanks Removed
  C 14 21 40 32 0 0

Changes by File

File Language Code Added Code Removed Comments Added Comments Removed Blanks Added Blanks Removed
src/backend/access/heap/pruneheap.c C 14 21 40 32 0 0