Postgres Pro launches a dedicated background freezer worker. All backends communicate with the worker using a UDP socket to send information about recently modified pages and completed transactions to this worker. This information is accumulated in special lists individual for each table. When the number of modified pages in the list exceeds the threshold set with the bgfreezer_pages_per_rel_to_clean configuration parameter, this list is queued for vacuuming and freezing. The worker starts processing this queue after being notified that the transaction has completed. While the list of pages is being vacuumed, the worker acquires a read lock on the corresponding table. This prevents parallel operations, such as dropping or truncating the table, during the background freezer activity. For each page of the list, the background freezer worker vacuums and freezes the tuples that meet the relevant conditions. For more information, see Section 24.1.6. If after vacuuming and freezing all page tuples are visible and frozen and the relevant visibility map page is in memory, background freezer sets the visibility and freezing bits on the visibility map page. After deleted tuples are vacummed on the data page, the free space map (FSM) data is also adjusted. Without such an adjustment, vacuumed pages will not be reused.

The background freezer mechanism only applies to permanent table pages, leaving temporary tables unaffected.

Background freezer helps with issues that may occur when a large number of temporary tables is frequently created and dropped. In such cases, autovacuum may not be fast enough to vacuum system tables causing them to bloat. This primarily applies to pg_type, pg_attribute, pg_class, pg_depend, and pg_index. Background freezer vacuums deleted tuples in memory, thereby considerably decreasing system table bloat.

To enable background freezer, set the enable_background_freezer configuration parameter to on.