public inbox for [email protected]  
help / color / mirror / Atom feed
From: Alexey Makhmutov <[email protected]>
To: Melanie Plageman <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Andres Freund <[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 17:30:51 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAAKRu_bgkOQqu3K5n4YLRsNBZqJ9Rjg80ROqgKSr2UGz4b5hUg@mail.gmail.com>
References: <CAAKRu_Yz9x0sejBa5ov_LJ5sMOSKM3AeKOFUg+fQpNqyMmxwRA@mail.gmail.com>
	<CA+TgmoasgmY7mzZutGisD2=3y7BwwPUS=oNsQoORKRg1r69fEA@mail.gmail.com>
	<CAAKRu_Y7X=0UAQa5b_2Z20z5+UPBtDbjazYD9228jmj-d9NpQA@mail.gmail.com>
	<CA+Tgmob05A07mtzeUGwxQKU9KZSf4BhJU9CXgcy4Pe3ZHxZrcw@mail.gmail.com>
	<CAAKRu_YX0NP_yhXvPnvDRjVxxprsRBM-_MZzAJskfMydMQ=ETA@mail.gmail.com>
	<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>

Hi Melanie,

Sorry for the late note for the already committed patch, but I have a 
question on the last part of the 'heap_xlog_prune_freeze' function 
related to the FSM update (it was committed in add323d -'Eliminate 
XLOG_HEAP2_VISIBLE from vacuum phase III').

Currently it contains the following logic:
	
...
Size	freespace = 0;
...
if (BufferIsValid(buffer))
{
	if ((xlrec.flags & (XLHP_HAS_REDIRECTIONS |
						XLHP_HAS_DEAD_ITEMS |
						XLHP_HAS_NOW_UNUSED_ITEMS)) ||
		(vmflags & VISIBILITYMAP_VALID_BITS))
		freespace = PageGetHeapFreeSpace(BufferGetPage(buffer));
...
	UnlockReleaseBuffer(buffer);
}
...
if (freespace > 0)
	XLogRecordPageWithFreeSpace(rlocator, blkno, freespace);
...
		
My question is about the last check ('freespace > 0') - do we really 
want to call 'XLogRecordPageWithFreeSpace' only if 'freespace' is 
greater than 0? As I understand, the zero value is a perfectly valid 
output of the 'PageGetHeapFreeSpace' call (i.e. page has no space or no 
free line items while we mark all rows as frozen/visible), but with the 
current implementation we will skip FSM update in such case. Maybe we 
need to use additional flag (i.e. 'need_fsm_update'), set it before 
calling 'PageGetHeapFreeSpace' and then check before the 
'XLogRecordPageWithFreeSpace' invocation?

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