public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Xing Guo <[email protected]>
Cc: [email protected]
Subject: Re: Fix an incorrect assertion condition in mdwritev().
Date: Sat, 25 May 2024 23:59:05 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CACpMh+BM-VgKeO7suPG-VHTtpzJ+zsbDPwVHu42PLp-iTk0z+A@mail.gmail.com>
<[email protected]>
Michael Paquier <[email protected]> writes:
> On Sat, May 25, 2024 at 11:52:22PM +0800, Xing Guo wrote:
>> #ifdef CHECK_WRITE_VS_EXTEND
>> - Assert(blocknum < mdnblocks(reln, forknum));
>> + Assert(blocknum + nblocks <= mdnblocks(reln, forknum));
>> #endif
> Yes, it looks like you're right that this can be made stricter,
> computing the number of blocks we're adding in the number calculated
> (aka adding one block to this number fails immediately at initdb).
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? (If not, it's
not a reason to block this patch; but let's think about it
while we're here.)
regards, tom lane
view thread (6+ 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]
Subject: Re: Fix an incorrect assertion condition in mdwritev().
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