Re: WAL replay bugs

TODO

On Wed, Jul 2, 2014 at 5:32 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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