Message-ID: <94e5d94f-c28c-4921-9e03-c76c78d45275@postgrespro.ru>
Date: Thu, 23 Apr 2026 17:17:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Two issues leading to discrepancies in FSM data on the standby
 server
To: Melanie Plageman <melanieplageman@gmail.com>,
 Alexander Korotkov <aekorotkov@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, pgsql-hackers@postgresql.org
References: <596c4f1c-f966-4512-b9c9-dd8fbcaf0928@postgrespro.ru>
 <6A6138F4-8D6F-463D-9ECC-38C0881308FE@yandex-team.ru>
 <60b79f39-69e5-4c73-a708-6ef1fd5e7980@postgrespro.ru>
 <CAAKRu_Yj5DgvwAEHgM1PkoueQE0s7JSbs+XHO=oFj1Y+pzVJ3A@mail.gmail.com>
 <CAPpHfdv181MSf8-5mDm8+x9i02CWn=B6vMj5ATTpCbChu5co3w@mail.gmail.com>
 <CAAKRu_a3hmATsHOhCEoAgGJuyVQ9UNKnHm84pP+_G+MWovTOJA@mail.gmail.com>
 <CAPpHfdup6dChoejUk0TLkyzy9SVKPFMTUhUXwphP=GsXg-pGUw@mail.gmail.com>
 <CAAKRu_ZNAsUv9TPJ0bxxfTj-KyTMVidqWUhsfjKDmUrA4DRSkQ@mail.gmail.com>
Content-Language: en-US
From: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
In-Reply-To: 
 <CAAKRu_ZNAsUv9TPJ0bxxfTj-KyTMVidqWUhsfjKDmUrA4DRSkQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/94e5d94f-c28c-4921-9e03-c76c78d45275%40postgrespro.ru>
Precedence: bulk

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