Fix FSM range endpoint after relation extension
Hi,
While looking at RelationAddBlocks(), I noticed that it calls
FreeSpaceMapVacuumRange() with last_block as the end of the range.
FreeSpaceMapVacuumRange() treats the end block as exclusive, so the last
newly recorded FSM block is not propagated. This looks like it may
simply have missed converting the inclusive last_block into the
exclusive endpoint expected by FreeSpaceMapVacuumRange().
The first patch contains the actual fix, by passing last_block + 1. The
second patch is only meant to demonstrate the issue: it adds a small
test_fsm regression test using a non-empty range across an FSM leaf page
boundary, showing that excluding the last block can leave it
unsearchable after the earlier block is consumed.
---
Regards,
Jingtang
Attachments:
0001-hio-Include-last-block-in-FSM-vacuum-range.patchapplication/octet-stream; name=0001-hio-Include-last-block-in-FSM-vacuum-range.patchDownload+1-2
0002-test_fsm-Cover-FSM-range-endpoint-propagation.patchapplication/octet-stream; name=0002-test_fsm-Cover-FSM-range-endpoint-propagation.patchDownload+207-1
Hi hackers,
Just following up on this thread, since there hasn't been any feedback yet.
The patches are unchanged since the original posting. The fix is a
one-line correction to pass last_block + 1 as the exclusive endpoint
to FreeSpaceMapVacuumRange(), and the second patch includes a focused
test crossing an FSM leaf-page boundary.
If the diagnosis and fix look reasonable, I would greatly appreciate
a review.
---
Regards,
Jingtang
On Mon, Jul 13, 2026 at 12:28:01PM +0800, Jingtang Zhang wrote:
Just following up on this thread, since there hasn't been any feedback yet.
The patches are unchanged since the original posting. The fix is a
one-line correction to pass last_block + 1 as the exclusive endpoint
to FreeSpaceMapVacuumRange(), and the second patch includes a focused
test crossing an FSM leaf-page boundary.If the diagnosis and fix look reasonable, I would greatly appreciate
a review.
Adding the related committers in CC is a good first step. Please also
make sure that this patch is registered in the commit fest, so as we
don't forget about it (aka there is a lot of traffic on this list, and
everybody is busy with their own things, so it may take time before
somebody is able to look back at what you have):
https://commitfest.postgresql.org/60/
Thanks,
--
Michael
On Mon, Jul 13, 2026 at 12:28 AM Jingtang Zhang <mrdrivingduck@gmail.com> wrote:
The patches are unchanged since the original posting. The fix is a
one-line correction to pass last_block + 1 as the exclusive endpoint
to FreeSpaceMapVacuumRange(), and the second patch includes a focused
test crossing an FSM leaf-page boundary.If the diagnosis and fix look reasonable, I would greatly appreciate
a review.
Yes, this looks like a real bug and your proposed fix is the fix. In
practice, it won't affect things much -- only when the page is the
first of a new FSM page. The issue was introduced in 16, so it will
need to be backpatched all the way back. I'll try to get to it later
this week if someone else doesn't beat me to it.
- Melanie
On Wed, Jul 15, 2026 at 10:07 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
On Mon, Jul 13, 2026 at 12:28 AM Jingtang Zhang <mrdrivingduck@gmail.com> wrote:
The patches are unchanged since the original posting. The fix is a
one-line correction to pass last_block + 1 as the exclusive endpoint
to FreeSpaceMapVacuumRange(), and the second patch includes a focused
test crossing an FSM leaf-page boundary.If the diagnosis and fix look reasonable, I would greatly appreciate
a review.Yes, this looks like a real bug and your proposed fix is the fix. In
practice, it won't affect things much -- only when the page is the
first of a new FSM page. The issue was introduced in 16, so it will
need to be backpatched all the way back. I'll try to get to it later
this week if someone else doesn't beat me to it.
Okay, I just pushed it. Thanks for the report!
- Melanie