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

From Robert Haas
Subject Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)
Date
Msg-id CA+TgmobmNsHeE5tV=MVR3A9apQkkTxMqjfEi=529R+ih-HH9rg@mail.gmail.com
Whole thread Raw
In response to Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 31, 2022 at 4:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Seems like that in itself is a a lousy idea.  Either the code should
> respect the abstraction, or it shouldn't be declaring the variable
> as a relptr in the first place.

Yep. I think it should be respecting the abstraction, but the 2016
version of me failed to realize the issue when committing 13e14a78ea1.
Hindsight is 20-20, perhaps.

> > So we can fix this by:
> > 1. Using a relative pointer value other than 0 to represent a null
> > pointer. Andres suggested (Size) -1.
> > 2. Not storing the free page manager for the DSM in the main shared
> > memory segment at byte offset 0.
> > 3. Dropping the assertion while loudly singing "la la la la la la".
>
> I'm definitely down on #3, because that just leaves the ambiguity
> in place to bite somewhere else in future.  #1 would work as long
> as nobody expects memset-to-zero to produce null relptrs, but that
> doesn't seem very nice either.

Well, that's a good point that I hadn't considered, actually. I was
thinking I'd only picked 0 as the value out of adherence to
convention, but I might have had this in mind too, at the time.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: generate_series for timestamptz and time zone problem
Next
From: Robert Haas
Date:
Subject: Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)