From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Xing Guo <higuoxing@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: Fix an incorrect assertion condition in mdwritev().
In-reply-to: <1933.1716695945@sss.pgh.pa.us>
References: <CACpMh+BM-VgKeO7suPG-VHTtpzJ+zsbDPwVHu42PLp-iTk0z+A@mail.gmail.com> <ZlKArtPhzn868no_@paquier.xyz> <1933.1716695945@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 25 May 2024 23:59:05 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1991.1716696526.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 26 May 2024 00:08:46 -0400
Message-ID: <1992.1716696526@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1992.1716696526%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Hmm ... I agree that this is better normally.  But there's an
> edge case where it would fail to notice a problem that the
> existing code does notice: if blocknum is close to UINT32_MAX
> and adding nblocks causes it to wrap around to a small value.
> Is there an inexpensive way to catch that?

After a few minutes' thought, how about:

	Assert((uint64) blocknum + (uint64) nblocks <=3D (uint64) mdnblocks(reln,=
 forknum));

This'd stop being helpful if we ever widen BlockNumber to 64 bits,
but I think that's unlikely.  (Partitioning seems like a better answer
for giant tables.)

			regards, tom lane