From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MaxOffsetNumber versus MaxHeapTuplesPerPage |
Date: | 2007-10-25 14:48:24 |
Message-ID: | 15674.1193323704@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Zdenek Kotala wrote:
>> Is there any reason to have both these macros? By my opinion
>> MaxHeapTuplesPerPage is more accurate and it should replace all
>> MaxOffsetNumber occurrence.
> We use MaxOffsetNumber with index pages as well.
> At quick glance, the only places I can see where we could replace
> MaxOffsetNumber with MaxHeapTuplesPerPage, are in vacuum.c and
> vacuumlazy.c, where we allocate arrays big enough to hold potentially a
> full page's worth of tuples. We could change those, but it's hardly
> worth the trouble.
There is also a difference in intent: MaxOffsetNumber is selected so
that it's physically impossible to have more than that many offsets on a
page, and so it's safe to use an array sized that way without any
overflow checks. MaxHeapTuplesPerPage is the most that *should* be
there but one can think of corner cases where there could be more (eg,
limit on number of redirect pointers hasn't been enforced correctly,
not to mention flat-out corrupt page). If there is any code using
MaxHeapTuplesPerPage as an array size and not backstopping it with an
explicit overflow check, that would be a bug IMHO.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2007-10-25 14:58:06 | Re: Datum should be defined outside postgres.h |
Previous Message | Alvaro Herrera | 2007-10-25 14:45:55 | pgsql: Extract catalog info for error reporting before an error actually |