Heikki Linnakangas wrote:
> The "special" area in a BRIN page looks like this:
>
> >/* special space on all BRIN pages stores a "type" identifier */
> >#define BRIN_PAGETYPE_META 0xF091
> >#define BRIN_PAGETYPE_REVMAP 0xF092
> >#define BRIN_PAGETYPE_REGULAR 0xF093
> >...
> >typedef struct BrinSpecialSpace
> >{
> > uint16 flags;
> > uint16 type;
> >} BrinSpecialSpace;
>
> I believe this is supposed to follow the usual convention that the last two
> bytes of a page can be used to identify the page type. SP-GiST uses 0xFF82,
> while GIN uses values 0x00XX.
>
> However, because the special size is MAXALIGNed, the 'type' field are not
> the last 2 bytes on the page, as intended. I'd suggest just adding "char
> padding[6]" in BrinSpecialSpace, before 'flags'. That'll waste 4 bytes on
> 32-bit systems, but that seems acceptable.
Ouch. You're right. I don't understand why you suggest to use 6 bytes,
though -- that would make the struct size be 10 bytes, which maxaligns
to 16, and so we're back where we started. Using 4 bytes does the
trick.
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;
It's a bit ugly, but it seems to work for me on x86-64 ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
