Re: Wrap access to Oid in HeapTupleHeader

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> AssertMacro((tup)->t_hoff == ExpectedLen(tup))

> where

> #define ExpectedLen(tup) MAXALIGN( \
> offsetof(HeapTupleHeaderData, t_bits) + \
> (((tup)->t_infomask | HEAP_HASNULL) \
> ? BITMAPLEN((tup)->t_natts) : 0) \
> )
> Sure, this is even more expensive, but it catches 255 out of 256
> errors.

Yikes. Once per routine would be one thing, but once per macro call?

> On Mon, 01 Jul 2002 10:40:34 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote
> on -hackers:
>> Also, you could be a little more conservative about
>> adding Asserts --- those are not free, at least not from a development
>> point of view, so I object to adding multiple redundant Asserts in
>> hotspot routines.

> Messing around with tuple headers is delicate stuff IMHO, and I don't
> want to be remembered as the man who broke the best open source
> database. So I cowardly put in those Asserts ...

The other side of the coin is that if you break anything, it will be
*extremely* obvious. I'm not particularly worried.

You might want to think about the fact that all the FooIsValid(fooptr)
macros expand to just "fooptr != NULL", and not to some amazingly
complete test of validity of the pointed-to object. There's a tradeoff
that has to be made here between development cycles and the probability
of actually catching any bugs. I think the asserts you've been
submitting are well over into the diminishing-returns end of that
spectrum.

> If you are concerned
> about performance in development versions, is there any chance you
> could be convinced of a configurable paranoia level?

The way we usually handle that is #define symbols that increase the
debuggability of a particular subsystem. Perhaps you could provide
a symbol named something like DEBUG_TUPLE_ACCESS that causes
more-paranoid versions of the tuple access macros to be chosen.

regards, tom lane