Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 46144650E8F for ; Fri, 4 Jul 2008 08:07:18 -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 08963-01 for ; Fri, 4 Jul 2008 08:07:10 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by postgresql.org (Postfix) with ESMTP id B1BE9650E7F for ; Fri, 4 Jul 2008 08:07:14 -0300 (ADT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m64B7CFr014564 for ; Fri, 4 Jul 2008 11:07:12 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3H00I01AFQD400@fe-emea-09.sun.com> (original mail from Zdenek.Kotala@Sun.COM) for pgsql-patches@postgresql.org; Fri, 04 Jul 2008 12:07:12 +0100 (BST) Received: from [192.168.1.101] ([89.103.109.2]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3H00A4VAVO2P50@fe-emea-09.sun.com>; Fri, 04 Jul 2008 12:07:01 +0100 (BST) Date: Fri, 04 Jul 2008 13:04:15 +0200 From: Zdenek Kotala Subject: Re: page macros cleanup In-reply-to: <486E01B0.9050100@enterprisedb.com> To: Heikki Linnakangas Cc: Pavan Deolasee , PostgreSQL-patches Message-id: <486E03AF.2040402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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> <486E01B0.9050100@enterprisedb.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200807/63 X-Sequence-Number: 6757 Heikki Linnakangas napsal(a): > 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. 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