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

Re: page macros cleanup

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: page macros cleanup
Date: 2008-07-04 11:04:15
Message-ID: 486E03AF.2040402@sun.com (view raw or flat)
Thread:
Lists: pgsql-patches
Heikki Linnakangas napsal(a):
> Pavan Deolasee wrote:
>> On Fri, Jul 4, 2008 at 3:37 PM, Heikki Linnakangas
>> <heikki(at)enterprisedb(dot)com> wrote:
>>>
>>> I think this is the way it should be:
>>>
>>> #define HashMaxItemSize \
>>>        (BLCKSZ - \
>>>         SizeOfPageHeaderData - \
>>>         MAXALIGN(sizeof(HashPageOpaqueData)) - \
>>>         sizeof(ItemIdData))
>>>
>>
>> I am wondering if this would fail for corner case if HashMaxItemSize
>> happened to be unaligned. For example, if (itemsz < HashMaxItemSize <
>> MAXALIGN(itemsz), PageAddItem() would later fail with a not-so-obvious
>> error. Should we just MAXALIGN_DOWN the HashMaxItemSize ?
> 
> No, there's a itemsz = MAXALIGN(itemsz) call before the check against 
> HashMaxItemSize.

It is tru, but id somebody will use HashMaxItemSize in different place in the 
future he could omit to use same approach. See tuptoaster.h how TOAST_MAX_CHUNK 
is defined or BTMaxItemSize in nbtree.h.

Pavan's comments is correct. It should give same result as my implementation 
(because BLCKSZ is aligned), but it is better readable and consistent with other.

	Zdenek

-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql


In response to

pgsql-patches by date

Next:From: Pavan DeolaseeDate: 2008-07-04 11:05:36
Subject: Re: page macros cleanup
Previous:From: Heikki LinnakangasDate: 2008-07-04 10:55:44
Subject: Re: page macros cleanup

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