From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: BRIN page type identifier
In-reply-to: <20150309223505.GT3291@alvh.no-ip.org>
References: <546A16EF.9070005@vmware.com>
 <20150309223505.GT3291@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
 message dated "Mon, 09 Mar 2015 19:35:05 -0300"
Date: Mon, 09 Mar 2015 19:34:41 -0400
Message-ID: <8620.1425944081@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I wonder if this is permissible and whether it will do the right thing
> on 32-bit systems:

> /*
>  * Special area of BRIN pages.
>  *
>  * We add some padding bytes to ensure that 'type' ends up in the last two
>  * bytes of the page, for consumption by pg_filedump and similar utilities.
>  * (Special space is MAXALIGN'ed).
>  */
> typedef struct BrinSpecialSpace
> {
> 	char		padding[MAXALIGN(1) - 2 * sizeof(uint16)];
> 	uint16		flags;
> 	uint16		type;
> } BrinSpecialSpace;

I should expect that to fail altogether on 32-bit machines, because
the declared array size will be zero.

You could try something like

typedef struct BrinSpecialSpace
{
	uint16		vector[MAXALIGN(1) / sizeof(uint16)];
} BrinSpecialSpace;

and then some access macros to use the last and next-to-last
elements of that array.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers