Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)
Дата
Msg-id 351605.1654035253@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands