Re: Open 7.3 items: heap tuple header

Manfred Koizar wrote:
> On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
> <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> >
> > P O S T G R E S Q L
> >
> > 7 . 3 O P E N I T E M S
> >
> >improve macros in new tuple header code (Manfred)
>
> ISTM there's no consensus about what "improve" means. I tried to
> start discussing this after my vacation, but apparently people had
> better things to do.

OK.

> On Wed, 07 Aug 2002 16:16:14 +0200, I wrote ("Heap tuple header
> issues"):
> :. Transaction and command ids, performance
> :
> :I offered to provide cheaper versions of GetCmin and GetCmax to be
> :used by the tqual routines. These version would reduce additional CPU
> :work from two infomask compares to one. Is this still considered an
> :issue?
>
> However, I don't think this would lead to any measurable difference.

Yep.

> :. Transaction and command ids, robustness
> :
> :I'm still of the opinion that putting *more* knowledge into the SetXxx
> :macros is the way to go. The runaway INSERT bug could as well have
> :been fixed by changing SetCmax to do nothing, if HEAP_XMAX_INVALID is
> :set, and changing SetXmaxInvalid to set HEAP_XMAX_INVALID. Likewise I
> :would change SetXmax to set HEAP_XMAX_INVALID, if xid ==
> :InvalidTransactionId, or reset it, if != (not sure about this). Same
> :for SetXminInvalid and SetXmin.
>
> This is the main point of disagreement: Tom Lane wants lighter
> macros, I want heavier macros. Which direction shall we go?

Could you or Tom explain that in a way that others could understand.

My guess is that you want the sanity checks in the macros, and Tom wants
more of them in the main code?

> :Further, I'll try to build a regression test using statement timeout
> :to detect runaway INSERT/UPDATE (the so called "halloween" problem).
>
> This won't hurt anyway. I'll start working on this.
>
> BTW, my changes have been criticized with words like "vague unease",
> "zero confidence", "very obviously not robust", "do not trust the
> current code at all" etc., while from day one all my patches have
> passed all regression tests.

I totally agree with you here. You code has been great, and it did
something (reduce tuple size) that no one else thought possible.

> This makes me wonder whether there is
> something wrong with the regression tests ...

However, I should add that the regression tests test only a small subset
of how the database has to operate. There are so many bizarre
conditions that we can't test them all.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073