Hi Alexander and Melanie,
Thank you very much for the attention to this thread!
On 4/22/26 17:15, Melanie Plageman wrote:
>>> I don't know how much of Alexey's reported issue was this vs
>>> PageGetFreeSpace() in heap_xlog_visible(). The MarkBufferDirty()
>>> change is easy to fix, so it probably makes sense to do so. I haven't
>>> investigated more about the PageGetFreeSpace() issue.
>> Makes sense. I suggest Alexey could clarify this.
The issue with 'PageGetFreeSpace' call is completely unrelated to the
other issue discussed in this thread (i.e. marking FSM buffer as dirty).
In my view it's just a small overlook in the ab7dbd6, which used
'PageGetFreeSpace' instead of 'PageGetHeapFreeSpace'. This latter
function calls ‘PageGetFreeSpace’ and additionally checks that there is
a space in line pointers section (i.e. checks that MaxHeapTuplesPerPage
is not exceeded). If MaxHeapTuplesPerfPage items are already created,
then free space for a heap block need to be reported as 0, as no new
tuple could be added to the page. Such case could be observed if page
has large number of redirect slots created as result of HOT cleanups.
Basically, every code working with heap pages should use
‘PageGetHeapFreeSpace’ rather than ‘PageGetFreeSpace’ and function
‘heap_xlog_visible’ is the only place in the code where
‘PageGetFreeSpace’ is used for heap pages. I think that situation with
difference between results of these two functions is rarely observed,
but it seems to be logical to just call the correct function in all cases.
This issue is present in all supported version (PG 14-18), but is not
present in current master for PG19 (as ‘heap_xlog_visible’ was removed
in a881cc9).
> Would be good also if he could add a 19 open item for the
> PageGetFreeSpace() thing (in the issues affecting back branches
> section) or register a patch for next commitfest (as a bug), so we
> don't forget about it.
Sure, I could just move this second patch (with test to reproduce the
problem) to a different thread and register a new commitfest entry for
it. Target version will be 14 (first supported version with the code).
As it cannot by applied on top of current master (as the problem was
already fixed for PG19 as result of a881cc9), so probably it will be
displayed in 'need rebase' status.
Thanks,
Alexey
