Message-ID: <ca23ba29-4efd-4328-a3e6-7893af9f6285@postgrespro.ru>
Date: Mon, 6 Apr 2026 18:32:03 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
To: Andres Freund <andres@anarazel.de>
Cc: Melanie Plageman <melanieplageman@gmail.com>,
 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>
References: 
 <CA+TgmoZef8XqRujP1NN=wJdV4SxOtu7rxRozsyAtaEvuVMZhEw@mail.gmail.com>
 <CAAKRu_YxD3UC3BXxS55jPjBC_yj_vn3FVoLvBMwQuHXGDXacGg@mail.gmail.com>
 <CA+TgmobYY2URHKBMh1NHo1zF3Z28TiS_+0aSyRYyBfvauCPZzA@mail.gmail.com>
 <CAAKRu_YOJ3VTKo4Z9vB2hGeTnwVWsL39gXH09vyBUQ7bGtDnKA@mail.gmail.com>
 <yn4zp35kkdsjx6wf47zcfmxgexxt4h2og47pvnw2x5ifyrs3qc@7uw6jyyxuyf7>
 <CAAKRu_ZiuR+YcUc7=TrgANbRakpzCu8X9zqR=Tf0fE6uDbfP1g@mail.gmail.com>
 <CA+TgmoYgCs=SEsohP6Z6R3KKsGaqFqvqxH8vQ_-nY4t+7rK8jg@mail.gmail.com>
 <CAAKRu_ZP-3=SaZykpwDBMJOdUKyW3Wm5JZfPFRR3L5Ac8ouq4w@mail.gmail.com>
 <CAAKRu_bgkOQqu3K5n4YLRsNBZqJ9Rjg80ROqgKSr2UGz4b5hUg@mail.gmail.com>
 <ead2f110-c736-48f5-99e1-023dc9acbf0b@postgrespro.ru>
 <7clovcjtacv6peujpfaimeynrkcd4anp6ohbdd3ncgtjo67anb@ylcccepdiuz2>
Content-Language: en-US
From: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
In-Reply-To: <7clovcjtacv6peujpfaimeynrkcd4anp6ohbdd3ncgtjo67anb@ylcccepdiuz2>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ca23ba29-4efd-4328-a3e6-7893af9f6285%40postgrespro.ru>
Precedence: bulk

Hi Andres,

On 4/6/26 17:44, Andres Freund wrote:
> I don't have a strong opinion on this, but I think it's pretty defensible to
> record only when there's free space. The whole goal of updating the FSM during
> recovery is to make sure that free space can be found fairly quickly after
> promotion (it's also beneficial in some crash recovery cases, but not that
> much).
> ... 
> Obviously the FSM is not crashsafe, so updating it with 0 during replay could
> avoid some unnecessary page reads after a promotion. But I'm not sure that
> that's particularly worth optimizing for.

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.

Thanks,
Alexey