Hello, At Thu, 3 Jul 2014 14:48:50 +0900, Michael Paquier <michael.paqu...@gmail.com> wrote in <cab7npqq2y3qkapasac6oxxqtwbvkkxcrftua0w+dx-j3i-l...@mail.gmail.com> > TODO ... > > 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. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
