TODO On Wed, Jul 2, 2014 at 5:32 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> 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 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. Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
