| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Xing Guo <higuoxing(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Fix an incorrect assertion condition in mdwritev(). |
| Date: | 2024-05-26 03:59:05 |
| Message-ID: | 1933.1716695945@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2024-05-26 04:00:33 | Re: AIX support |
| Previous Message | Alexander Korotkov | 2024-05-26 03:58:11 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |