On Wed, Dec 17, 2025 at 8:26 AM Amul Sul <[email protected]> wrote:
> Thanks for detailed reproducible steps, I can see the reported issue > and proposed patch fixes the same. Thanks for the review! > The deleted code you moved to mdtruncate() should be kept where it > was. We cannot ensure that every extension using this interface will > adhere to that requirement what the comment describes. Yeah, I've overlooked the case of extensions. I've moved back the InvalidBlockNumber assignment. Furthermore, an extension's routine might miss updating smgr_cached_nblocks. To ensure that updates smgr_cached_nblocks properly, we should also add an assertion after the call, like this: > > /* > * Ensure that the local smgr_cached_nblocks value is updated. > */ > Assert(reln->smgr_cached_nblocks[forknum[i]] != > InvalidBlockNumber); Good point. I've added the assertion. I wonder how critical it is to have an up to date value of smgr_cached_nblocks after smgr_truncate. Leaving InvalidBlockNumber was also an option as the next user will ask the kernel for the real size. There are some functions like DropRelationBuffers which rely only on the cached value, so it's probably safer to keep the same behaviour. Regards, Anthonin Bonnefoy
v2-0001-Fix-unexpected-data-beyond-EOF-on-replica-restart.patch
Description: Binary data
