Re: More heap tuple header fixes
От | Manfred Koizar |
---|---|
Тема | Re: More heap tuple header fixes |
Дата | |
Msg-id | fr2mjugtkvd96bofig16850sf30s5mp9ki@4ax.com обсуждение исходный текст |
Ответ на | Re: More heap tuple header fixes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: More heap tuple header fixes
Re: More heap tuple header fixes |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: