On Wed, Jul 2, 2014 at 5:32 PM, Kyotaro HORIGUCHI
<> wrote:
> bufcapt.c: 326 memcpy(&tail, &page[BLCKSZ - 2], 2);
>   This seems duzzling..  Isn't "*(uint16*)(&page[BLCKSZ - 2])" applicable?
Well yes it is.

>   Pehaps this is showing that no tidy or generalized way to tell
>   what a page is used for. Many of the modules which have their
>   own page format has a magic value and the values seem to be
>   selected carefully. But no one-for-all method to retrieve that.
You have a point here.

>   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
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.

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to