From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-06-03 22:24:07 |
Message-ID: | 20240603222407.rhds5yb52jshdykw@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-06-04 07:17:51 +0900, Michael Paquier wrote:
> On Sun, May 26, 2024 at 12:08:46AM -0400, Tom Lane wrote:
> > After a few minutes' thought, how about:
> >
> > Assert((uint64) blocknum + (uint64) nblocks <= (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.)
>
> No idea if this will happen or not, but that's not the only area where
> we are going to need a native uint128 implementation to control the
> overflows with uint64.
I'm confused - isn't using common/int.h entirely sufficient for that? Nearly
all architectures have more efficient ways to check for 64bit overflows than
doing actual 128 bit math.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-06-03 22:43:41 | Re: Fix an incorrect assertion condition in mdwritev(). |
Previous Message | Michael Paquier | 2024-06-03 22:17:51 | Re: Fix an incorrect assertion condition in mdwritev(). |