Re: Open 7.3 items: heap tuple header - Mailing list pgsql-hackers

Manfred Koizar wrote:
> On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
> <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073