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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Yeah, so when I created this stuff in the first place, I figured that
> it wasn't a problem if we reserved relptr == 0 to mean a NULL pointer,
> because you would never have a relative pointer pointing to the
> beginning of a DSM, because it would probably always start with a
> dsm_toc. But when Thomas made it so that DSM allocations could happen
> in the main shared memory segment, that ceased to be true. This
> example happened not to break because we never use relptr_access() on
> fpm->self. We do use fpm_segment_base(), but that accidentally fails
> to break, because instead of using relptr_access() it drills right
> through the abstraction and doesn't have any kind of special case for
> 0.

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.

> 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.

On the whole, wasting MAXALIGN worth of memory seems like the least bad
alternative, but I wonder if we ought to do it right here as opposed
to somewhere in the DSM code proper. Why is this DSM space not like
other DSM spaces in starting with a TOC?

regards, tom lane