Re: Fix possible 'unexpected data beyond EOF' on replica restart - Mailing list pgsql-hackers

From Anthonin Bonnefoy
Subject Re: Fix possible 'unexpected data beyond EOF' on replica restart
Date
Msg-id CAO6_XqojxYb=j_rqSi_MH-DB=tZ-OtMQHqEx6xRh9DQrr2uDuQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix possible 'unexpected data beyond EOF' on replica restart  (Amul Sul <sulamul@gmail.com>)
List pgsql-hackers
On Wed, Dec 17, 2025 at 8:26 AM Amul Sul <sulamul@gmail.com> 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
Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: DOC: Fix formatting of ALTER TABLE REPLICA IDENTITY documentation
Next
From: Bertrand Drouvot
Date:
Subject: Re: Report bytes and transactions actually sent downtream