[ paths crossed in mail ]
I wrote:
> This way, accesses to "flags" require no source code changes.
> You still need a macro to map "type" onto the last element of
> the vector, but there's probably about one reference to "type"
> in the source code so it shouldn't be too painful.
Ah, nevermind, I
I wrote:
> 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.
On second thought, consider
typedef struct Bri
Tom Lane wrote:
> Alvaro Herrera writes:
> > typedef struct BrinSpecialSpace
> > {
> > charpadding[MAXALIGN(1) - 2 * sizeof(uint16)];
> > uint16 flags;
> > uint16 type;
> > } BrinSpecialSpace;
>
> I should expect that to fail altogether on 32-bit machine
Alvaro Herrera 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 s
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_REVMAP0xF092
> >#define
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_REVMAP0xF092
#define BRIN_PAGETYPE_REGULAR 0xF093
...
typ
