Re: Two issues leading to discrepancies in FSM data on the standby server - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Two issues leading to discrepancies in FSM data on the standby server
Date
Msg-id 6A6138F4-8D6F-463D-9ECC-38C0881308FE@yandex-team.ru
Whole thread Raw
In response to Two issues leading to discrepancies in FSM data on the standby server  (Alexey Makhmutov <a.makhmutov@postgrespro.ru>)
Responses Re: Two issues leading to discrepancies in FSM data on the standby server
List pgsql-hackers
Hi!

Very interesting cases!

> On 20 Mar 2026, at 06:32, Alexey Makhmutov <a.makhmutov@postgrespro.ru> wrote:
>
> Attached are separate patches, which tries to fixes both these problems – calling ‘MarkBufferDirty’ instead of
‘MarkBufferDirtyHint’in the first case and replacing ‘PageGetFreeSpace’ with ‘PageGetHeapFreeSpace’ in the second case. 


Patch 0001 - MarkBufferDirty() instead of MarkBufferDirtyHint() in XLogRecordPageWithFreeSpace().
Yes, MarkBufferDirtyHint() is no-op in recovery and it's the only case I found of using MarkBufferDirtyHint()
in redo.
Originally in e981653 was used MarkBufferDirty() but 96ef3b8 flipped to MarkBufferDirtyHint().
Neither of these commits provided a comment on why this version was chosen. I think if we fix it we must comment
things.


Patch 0002 - PageGetHeapFreeSpace instead of PageGetFreeSpace in heap_xlog_visible.
This seems to be just an oversight in ab7dbd6. Every other call to XLogRecordPageWithFreeSpace() uses
PageGetHeapFreeSpace().
And this seems correct to me, but a bit odd. Why indexes do not update FSM via this routine?

It seems indexes do not log free pages at all, relying on index vacuum to rebuild fsm on Standby.

Nice catch!


Best regards, Andrey Borodin.






pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)
Next
From: Fujii Masao
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication