On Sat, 20 Jul 2002 16:27:14 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>I'd recommend redesigning the HeapTupleHeaderSet macros so that they
>do not do any setting of t_infomask bits, or even take any conditional
>action based on them,
The HEAP_XMIN_IS_XMAX bit is exclusively managed by these macros.
Pulling the handling of this bit out of the macros and spreading it to
the places, where the macros are used, cannot make the whole thing
more robust. This would mean, the caller had to decide whether to
store Cmax into t_cid or t_xmax...
> but solely Assert() that the bits are already
>in the appropriate state to allow storing of the value to be stored.
>Then, all uses have to be checked to ensure that t_infomask is coerced
>into the right state *before* doing HeapTupleHeaderSetFoo.
Apart from HEAP_XMIN_IS_XMAX this was my intention; we already do
this with HEAP_MOVED. I could add an assertion to SetCmax:
Assert(!((tup)->t_infomask & HEAP_XMAX_INVALID));
OTOH I thought about putting *more* logic into the macros to make
their use less fragile. For example SetXmaxInvalid could set the
HEAP_XMAX_INVALID bit, likewise SetCminInvalid with XMIN_INVALID.
Anyway, with this patch applied the heap tuple header changes should
be able to survive the next two weeks. I don't want to hack together
a quick change now, before I go on vacation. Let's find the perfect
solution, when I'm back ...
Servus
Manfred