public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexey Makhmutov <[email protected]>
To: Andres Freund <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date: Mon, 6 Apr 2026 18:32:03 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <7clovcjtacv6peujpfaimeynrkcd4anp6ohbdd3ncgtjo67anb@ylcccepdiuz2>
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>
<[email protected]>
<7clovcjtacv6peujpfaimeynrkcd4anp6ohbdd3ncgtjo67anb@ylcccepdiuz2>
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/[email protected],
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/[email protected]
(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
view thread (143+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox