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

From Heikki Linnakangas
Subject Re: Fix possible 'unexpected data beyond EOF' on replica restart
Date
Msg-id 7e5af8a3-45fe-4c37-9f66-e8bde6c5012b@iki.fi
Whole thread Raw
In response to Re: Fix possible 'unexpected data beyond EOF' on replica restart  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
List pgsql-hackers
On 12/01/2026 10:34, Anthonin Bonnefoy wrote:
> Here's a new version with a bit of rewording.

Applied to all branches. Thanks!

I left out this comment change on smgrtruncate():

> @@ -870,6 +870,9 @@ smgrnblocks_cached(SMgrRelation reln, ForkNumber forknum)
>   * be called in a critical section, but the current size must be checked
>   * outside the critical section, and no interrupts or smgr functions relating
>   * to this relation should be called in between.
> + *
> + * If the specified number of blocks is higher than the current size, the
> + * request is ignored when we are InRecovery, otherwise, an error is raised.
>   */
>  void
>  smgrtruncate(SMgrRelation reln, ForkNumber *forknum, int nforks,

I would love to have a comment along those lines, but I think it's 
misleading here, because smgrtruncate() actually does a few things even 
when the requested size is greater than the current size: it 
nevertheless calls DropRelationBuffers(), CacheInvalidateSmgr(), and 
updates the cached sizes in the SmgrRelation. So it seems misleading to 
say the request is ignored.

I wasn't sure how to phrase that, so I just left out that comment 
change. I'm open to proposals on a good wording though.

(The similar comment in mdnblocks() is accurate, mdnblocks() bails out 
very early, so I kept that)

- Heikki




pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Proposal to allow setting cursor options on Portals
Next
From: Sami Imseih
Date:
Subject: Re: Cleaning up PREPARE query strings?