Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Thomas Munro <thomas.munro@gmail.com>
Date: 2022-05-31T20:58:24Z
Lists: 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
Commits
-
Fix relptr's encoding of the base address.
- 99504ff8265e 14.5 landed
- 7201cd18627a 15.0 landed
-
Suppress compiler warning in relptr_store().
- e07d4ddc55fd 15.0 cited