Re: BRIN page type identifier

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: BRIN page type identifier
Date: 2015-03-09 22:35:05
Message-ID: 20150309223505.GT3291@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-03-09 22:36:43 Re: InvokeObjectPostAlterHook() vs. CommandCounterIncrement()
Previous Message Andreas Karlsson 2015-03-09 22:24:34 Re: New functions