Skip site navigation (1) Skip section navigation (2)

Re: More heap tuple header fixes

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: More heap tuple header fixes
Date: 2002-07-23 22:02:30
Message-ID: 200207232202.g6NM2UB06849@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Your patch has been added to the PostgreSQL unapplied patches list at:

	http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Manfred Koizar wrote:
> On Sat, 20 Jul 2002 16:27:14 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-07-23 22:03:03
Subject: Re: More heap tuple header fixes
Previous:From: Bruce MomjianDate: 2002-07-23 21:52:39
Subject: Re: lock listing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group