Horton
Menu

Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

Melanie Plageman <melanieplageman@gmail.com>

View thread
From: Melanie Plageman <melanieplageman@gmail.com>
To: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kirill Reshke <reshkekirill@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2026-04-13T16:17:54Z
Lists: pgsql-hackers

Attachments

On Mon, Apr 6, 2026 at 11:32 AM Alexey Makhmutov
<a.makhmutov@postgrespro.ru> wrote:
>
> This makes sense. I'd like just to put some context here: I was checking
> the FSM update case in scope of the thread
> https://www.postgresql.org/message-id/flat/596c4f1c-f966-4512-b9c9-dd8fbcaf0928@postgrespro.ru,
> in which I was specifically looking at the case with outdated FSM data
> (showing lots of free space) on standby causing a significant
> performance hit after switchover. As example this include case with
> table having fillfactor<=80 which has prior bulk rows deletes +
> insertion. In this case (mostly) empty FSM block may be delivered to
> standby via FPI, but subsequent inserts may be lost due to the 20%
> heuristic. Moreover, updates to FSM may be lost even for blocks filled
> for more than 80% due to missing dirty flag as described in that thread.
>
> In my understanding the FSM update during processing of the
> 'heap_xlog_visible' function on standby was kind of 'last line of
> defense' for any corner case scenario with FSM update (as block would
> not be visited by the vacuum process once it's marked as 'all visible')
> and it was introduced in
> https://www.postgresql.org/message-id/20180802172857.5skoexsilnjvgruk@alvherre.pgsql
> (ab7dbd681) specifically for this purpose. Now, as logic of
> 'heap_xlog_visible' is merged into 'heap_xlog_prune_freeze', so this
> task is carried by this function.
>
> I fully agree that having exactly zero-space seems to be a very uncommon
> situation (and probably not reproducible with tables having
> fillfactor<=80). I've just noted that such case was processed by the old
> logic in the 'heap_xlog_visible', while current implementation in
> 'heap_xlog_prune_freeze' skips it.

The scenario causing inaccurate freespace maps after promotion is
technically possible though improbable. Moreover, I don't see a
downside to changing it. Patch I plan to commit is attached.

I don't quite understand why heap_xlog_insert() considers whether the
heap page was an FPI before updating the FSM though. I know we need
some heuristic to avoid doing it for every record, but the FPI
consideration doesn't make sense to me.

- Melanie

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Stabilize btree_gist test against on-access VM setting

  2. Stabilize plancache test against on-access VM setting

  3. Make local buffers pin limit more conservative

  4. Update FSM during prune/freeze replay even if freespace is zero

  5. Pass down information on table modification to scan nodes

  6. Thread flags through begin-scan APIs

  7. Remove PlannedStmt->resultRelations in favor of resultRelationRelids

  8. Make it cheap to check if a relation is modified by a query

  9. Keep newest live XID up-to-date even if page not all-visible

  10. Add pruning fast path for all-visible and all-frozen pages

  11. Detect and fix visibility map corruption in more cases

  12. Save vmbuffer in heap-specific scan descriptors for on-access pruning

  13. Avoid BufferGetPage() calls in heap_update()

  14. Initialize missing fields in CreateExecutorState()

  15. Prefix PruneState->all_{visible,frozen} with set_

  16. Add PageGetPruneXid() helper

  17. Move commonly used context into PruneState and simplify helpers

  18. Remove table_scan_analyze_next_tuple unneeded parameter OldestXmin

  19. Simplify visibility check in heap_page_would_be_all_visible()

  20. Rename LVRelState VM-related logging counters

  21. Fix flakiness in the pg_visibility VM-only vacuum test by using a temporary table.

  22. Refactor lazy_scan_prune() VM clear logic into helper

  23. Eliminate use of cached VM value in lazy_scan_prune()

  24. Combine visibilitymap_set() cases in lazy_scan_prune()

  25. Fix const qualification in prune_freeze_setup()

  26. Simplify vacuum visibility assertion

  27. Split heap_page_prune_and_freeze() into helpers

  28. Assert that cutoffs are provided if freezing will be attempted

  29. Split PruneFreezeParams initializers to one field per line

  30. Refactor heap_page_prune_and_freeze() parameters into a struct

  31. Make heap_page_is_all_visible independent of LVRelState

  32. Inline TransactionIdFollows/Precedes[OrEquals]()

  33. Add helper for freeze determination to heap_page_prune_and_freeze

  34. Bump XLOG_PAGE_MAGIC after xl_heap_prune change

  35. Correct prune WAL record opcode name in comment

  36. Add error codes when vacuum discovers VM corruption

  37. Remove unused xl_heap_prune member, reason

  38. Remove unneeded VM pin from VM replay

  39. Add assert and log message to visibilitymap_set

  40. Stamp HEAD as 19devel.

  41. Add error codes to some corruption log messages