At Thu, 3 Jul 2014 14:48:50 +0900, Michael Paquier <michael.paqu...@gmail.com> 
wrote in <cab7npqq2y3qkapasac6oxxqtwbvkkxcrftua0w+dx-j3i-l...@mail.gmail.com>
> >   Each type of page can be confirmed by the following way *if*
> >   its type is previously *hinted* except for gin.
> >
> >   btree    : 32bit magic at pd->opaque
> >   gin      : No magic
> >   gist     : 16-bit magic at ((GISTPageOpaque*)pd->opaque)->gist_page_id
> >   spgist   : 16-bit magic at ((SpGistPageOpaque*)pd->opaque)->spgist_page_id
> >   hash     : 16-bit magic at ((HashPageOpaque*)pd->paque)->hasho_page_id
> >   sequence : 16-bit magic at pd->opaque, the last 2 bytes of the page.
> >
> >   # Is it comprehensive? and correct?
> Sequence pages use the last 4 bytes. Have a look at sequence_magic in
> sequence.c.
> For btree pages we can use the last 2 bytes and a check on MAX_BT_CYCLE_ID.
> For gin, I'll investigate if it is possible to add a identifier like
> GIN_PAGE_ID, it would make the page analysis more consistent with the
> others. I am not sure for what the 8 bytes allocated for the special
> area are used now for though.
> >   The majority is 16-bit magic at the TAIL of opaque struct. If
> >   we can unify them into , say, 16-bit magic at
> >   *(uint16*)(pd->opaque) the sizeof() labyrinth become stable and
> >   simple and other tools which should identify the type of pages
> >   will be happy. Do you think we can do that?
> Yes I think so. I'll raise a different thread though as this is a
> different problem that what this patch is targeting. I would even
> imagine a macro in bufpage.c able to handle that well.

Ok, that being the case, this topic should be stashed and I'll
look into there regardless of it. Thank you.


Kyotaro Horiguchi
NTT Open Source Software Center

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

Reply via email to