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