Re: WAL replay bugs

Hello,

At Thu, 3 Jul 2014 14:48:50 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqQ2y3QkapAsaC6oXXQTWbVkkxCrfTuA0w+DX-j3i-LByQ(at)mail(dot)gmail(dot)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