| From: | Jingtang Zhang <mrdrivingduck(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Fix FSM range endpoint after relation extension |
| Date: | 2026-06-29 09:25:58 |
| Message-ID: | CAPsk3_Bx_vdybN=-DZu8HLStf+XnuFUBkLwxouONSMkWuO9oug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-hio-Include-last-block-in-FSM-vacuum-range.patch | application/octet-stream | 1.1 KB |
| 0002-test_fsm-Cover-FSM-range-endpoint-propagation.patch | application/octet-stream | 10.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rafia Sabih | 2026-06-29 09:27:17 | Re: Bypassing cursors in postgres_fdw to enable parallel plans |
| Previous Message | Ashutosh Sharma | 2026-06-29 09:13:00 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |