From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485) |
Date: | 2022-05-31 22:14:13 |
Message-ID: | 351605.1654035253@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Seems backwards to me. A relative pointer is supposed to point to
> something inside some range of memory, like a DSM gment -- it can
> never be legally used to point to anything outside that segment. So it
> seems to me that you could perfectly legally point to the second byte
> of the segment, but never to the -1'th byte.
Okay, I was thinking about it slightly wrong: relptr is defined as an
offset relative to some base address, not to its own address. As long
as you're prepared to assume that the base address really is the start
of the addressable area, then yeah the above argument works.
However, now that I've corrected that mistaken image ... I wonder if
it could make sense to redefine relptr as self-relative? That ought
to provide some notational savings since you'd only need to carry
around the relptr's own address not that plus a base address.
Probably not something to consider for v15 though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2022-05-31 22:14:25 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Robert Haas | 2022-05-31 22:04:36 | Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485) |