MIME-Version: 1.0
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>
 <ca23ba29-4efd-4328-a3e6-7893af9f6285@postgrespro.ru>
In-Reply-To: <ca23ba29-4efd-4328-a3e6-7893af9f6285@postgrespro.ru>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Mon, 13 Apr 2026 12:17:54 -0400
Message-ID: 
 <CAAKRu_bOGKc9U7Qr5X14g7ChOmBoQ9kqcMTQew1LfsvNQj9s4A@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
To: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
Cc: Andres Freund <andres@anarazel.de>,
	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>
Content-Type: multipart/mixed; boundary="000000000000f3765f064f59d383"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAKRu_bOGKc9U7Qr5X14g7ChOmBoQ9kqcMTQew1LfsvNQj9s4A%40mail.gmail.com>
Precedence: bulk

--000000000000f3765f064f59d383
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 6, 2026 at 11:32=E2=80=AFAM Alexey Makhmutov
<a.makhmutov@postgrespro.ru> wrote:
>
> 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-dd8fbc=
af0928@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<=3D80 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@alv=
herre.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<=3D80). I've just noted that such case was processed by the ol=
d
> logic in the 'heap_xlog_visible', while current implementation in
> 'heap_xlog_prune_freeze' skips it.

The scenario causing inaccurate freespace maps after promotion is
technically possible though improbable. Moreover, I don't see a
downside to changing it. Patch I plan to commit is attached.

I don't quite understand why heap_xlog_insert() considers whether the
heap page was an FPI before updating the FSM though. I know we need
some heuristic to avoid doing it for every record, but the FPI
consideration doesn't make sense to me.

- Melanie

--000000000000f3765f064f59d383
Content-Type: text/x-patch; charset="US-ASCII";
	name="0001-Update-FSM-when-updating-VM-even-if-freespace-is-zer.patch"
Content-Disposition: attachment;
	filename="0001-Update-FSM-when-updating-VM-even-if-freespace-is-zer.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mnxea7ip0>
X-Attachment-Id: f_mnxea7ip0

RnJvbSBlYjk0MDM2NzZkNjFjMzJmNDUxMzllZjY1NTkzNjYxODJhZmQ2MDhmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBNZWxhbmllIFBsYWdlbWFuIDxtZWxhbmllcGxhZ2VtYW5AZ21h
aWwuY29tPgpEYXRlOiBNb24sIDEzIEFwciAyMDI2IDExOjUwOjMyIC0wNDAwClN1YmplY3Q6IFtQ
QVRDSF0gVXBkYXRlIEZTTSB3aGVuIHVwZGF0aW5nIFZNIGV2ZW4gaWYgZnJlZXNwYWNlIGlzIHpl
cm8KCmFkZDMyM2RhNDBhIHN0YXJ0ZWQgdXBkYXRpbmcgdGhlIHZpc2liaWxpdHkgbWFwIGluIHRo
ZSBzYW1lIFdBTCByZWNvcmQKYXMgcHJ1bmluZyBhbmQgZnJlZXppbmcuIFRoaXMgaW5jbHVkZWQg
dXBkYXRpbmcgdGhlIGZyZWVzcGFjZSBtYXAgZHVyaW5nCnJlcGxheSwgd2hpY2ggd2UndmUgZG9u
ZSBzaW5jZSBhYjdkYmQ2ODEuCgphZGQzMjNkYTQwYSwgaG93ZXZlciwgY29uZGl0aW9uZWQgZG9p
bmcgc28gb24gdGhlcmUgYmVpbmcgPiAwIGZyZWVzcGFjZSwKd2hpY2ggZGlmZmVyZWQgZnJvbSB0
aGUgcHJldmlvdXMgc3RhdGUuIFRoZSBGU00gaXMgbm90IFdBTC1sb2dnZWQgYW5kIGlzCmluc3Rl
YWQgdXBkYXRlZCBoZXVyaXN0aWNhbGx5IG9uIHN0YW5kYnlzLiBJbiByYXJlIGNhc2VzLCBpZiB0
aGUgRlNNIGlzCm5vdCB1cGRhdGVkIHdoaWxlIHJlcGxheWluZyBpbnNlcnRzLCB0aGVyZSBpcyAw
IGZyZWVzcGFjZSwgYW5kIHZhY3V1bQpyZXBsYXkgZG9lc24ndCB1cGRhdGUgdGhlIEZTTSB3aGVu
IHNldHRpbmcgdGhlIHBhZ2UKYWxsLXZpc2libGUvYWxsLWZyb3plbiwgYWZ0ZXIgdGhlIHN0YW5k
YnkgaXMgcHJvbW90ZWQgYW5kIHJ1bnMgdmFjdXVtLAppdCBtYXkgc2tpcCB0aG9zZSBwYWdlcyBh
bmQgdGhlbiBwcm9wYWdhdGUgb3Zlcmx5IG9wdGltaXN0aWMgbnVtYmVycyB1cAp0aGUgRlNNLCBj
YXVzaW5nIHNsb3duZXNzIHdoZW4gc2VhcmNoaW5nIGZvciBmcmVlc3BhY2UgZm9yIG5ldyB0dXBs
ZXMuCgpGaXggaXQgYnkgYWx3YXlzIHVwZGF0aW5nIHRoZSBGU00gd2hlbiByZXBsYXlpbmcgc2V0
dGluZyB0aGUgVk0uCgpBdXRob3I6IE1lbGFuaWUgUGxhZ2VtYW4gPG1lbGFuaWVwbGFnZW1hbkBn
bWFpbC5jb20+ClJlcG9ydGVkLWJ5OiBBbGV4ZXkgTWFraG11dG92IDxhLm1ha2htdXRvdkBwb3N0
Z3Jlc3Byby5ydT4KRGlzY3Vzc2lvbjogaHR0cHM6Ly9wb3N0Z3IuZXMvbS9lYWQyZjExMC1jNzM2
LTQ4ZjUtOTllMS0wMjNkYzlhY2JmMGIlNDBwb3N0Z3Jlc3Byby5ydQotLS0KIHNyYy9iYWNrZW5k
L2FjY2Vzcy9oZWFwL2hlYXBhbV94bG9nLmMgfCA2ICsrKysrLQogMSBmaWxlIGNoYW5nZWQsIDUg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2Fj
Y2Vzcy9oZWFwL2hlYXBhbV94bG9nLmMgYi9zcmMvYmFja2VuZC9hY2Nlc3MvaGVhcC9oZWFwYW1f
eGxvZy5jCmluZGV4IGYzZjQxOWQzZGMxLi45ZWQ3MDI0ZTgxNCAxMDA2NDQKLS0tIGEvc3JjL2Jh
Y2tlbmQvYWNjZXNzL2hlYXAvaGVhcGFtX3hsb2cuYworKysgYi9zcmMvYmFja2VuZC9hY2Nlc3Mv
aGVhcC9oZWFwYW1feGxvZy5jCkBAIC0zOCw2ICszOCw3IEBAIGhlYXBfeGxvZ19wcnVuZV9mcmVl
emUoWExvZ1JlYWRlclN0YXRlICpyZWNvcmQpCiAJQnVmZmVyCQl2bWJ1ZmZlciA9IEludmFsaWRC
dWZmZXI7CiAJdWludDgJCXZtZmxhZ3MgPSAwOwogCVNpemUJCWZyZWVzcGFjZSA9IDA7CisJYm9v
bAkJZG9fdXBkYXRlX2ZzbSA9IGZhbHNlOwogCiAJWExvZ1JlY0dldEJsb2NrVGFnKHJlY29yZCwg
MCwgJnJsb2NhdG9yLCBOVUxMLCAmYmxrbm8pOwogCW1lbWNweSgmeGxyZWMsIG1haW5kYXRhcHRy
LCBTaXplT2ZIZWFwUHJ1bmUpOwpAQCAtMjExLDcgKzIxMiwxMCBAQCBoZWFwX3hsb2dfcHJ1bmVf
ZnJlZXplKFhMb2dSZWFkZXJTdGF0ZSAqcmVjb3JkKQogCQkJCQkJCVhMSFBfSEFTX0RFQURfSVRF
TVMgfAogCQkJCQkJCVhMSFBfSEFTX05PV19VTlVTRURfSVRFTVMpKSB8fAogCQkJKHZtZmxhZ3Mg
JiBWSVNJQklMSVRZTUFQX1ZBTElEX0JJVFMpKQorCQl7CiAJCQlmcmVlc3BhY2UgPSBQYWdlR2V0
SGVhcEZyZWVTcGFjZShCdWZmZXJHZXRQYWdlKGJ1ZmZlcikpOworCQkJZG9fdXBkYXRlX2ZzbSA9
IHRydWU7CisJCX0KIAogCQkvKgogCQkgKiBXZSB3YW50IHRvIGF2b2lkIGhvbGRpbmcgYW4gZXhj
bHVzaXZlIGxvY2sgb24gdGhlIGhlYXAgYnVmZmVyIHdoaWxlCkBAIC0yNDgsNyArMjUyLDcgQEAg
aGVhcF94bG9nX3BydW5lX2ZyZWV6ZShYTG9nUmVhZGVyU3RhdGUgKnJlY29yZCkKIAlpZiAoQnVm
ZmVySXNWYWxpZCh2bWJ1ZmZlcikpCiAJCVVubG9ja1JlbGVhc2VCdWZmZXIodm1idWZmZXIpOwog
Ci0JaWYgKGZyZWVzcGFjZSA+IDApCisJaWYgKGRvX3VwZGF0ZV9mc20pCiAJCVhMb2dSZWNvcmRQ
YWdlV2l0aEZyZWVTcGFjZShybG9jYXRvciwgYmxrbm8sIGZyZWVzcGFjZSk7CiB9CiAKLS0gCjIu
NDMuMAoK
--000000000000f3765f064f59d383--