Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 01F12650E8F for ; Fri, 4 Jul 2008 07:55:53 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 95267-10 for ; Fri, 4 Jul 2008 07:55:45 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 7706B650E7F for ; Fri, 4 Jul 2008 07:55:49 -0300 (ADT) thread-index: AcjdxKHlZHt00DMITAyb8LvpbJl+TQ== Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Received: from [80.222.70.18] ([80.222.70.18]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 06:56:37 -0400 Message-ID: <486E01B0.9050100@enterprisedb.com> Date: Fri, 04 Jul 2008 13:55:44 +0300 From: "Heikki Linnakangas" Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "Pavan Deolasee" Cc: "Zdenek Kotala" , "PostgreSQL-patches" Subject: Re: page macros cleanup References: <48529B83.9010907@sun.com> <2e78013d0807030450m4cab60d0jd99d1acce59fae56@mail.gmail.com> <486DD1D1.50604@sun.com> <2e78013d0807040150w393ad72codaf06a6ac12a83ce@mail.gmail.com> <486DF644.4070604@enterprisedb.com> <2e78013d0807040350m3b2913cfkceaa70d8f9d697c2@mail.gmail.com> In-Reply-To: <2e78013d0807040350m3b2913cfkceaa70d8f9d697c2@mail.gmail.com> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2008 10:56:37.0375 (UTC) FILETIME=[A18CD8F0:01C8DDC4] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200807/59 X-Sequence-Number: 6753 Pavan Deolasee wrote: > On Fri, Jul 4, 2008 at 3:37 PM, Heikki Linnakangas > 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com