From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL replay bugs |
Date: | 2014-07-03 05:48:50 |
Message-ID: | CAB7nPqQ2y3QkapAsaC6oXXQTWbVkkxCrfTuA0w+DX-j3i-LByQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Abhijit Menon-Sen | 2014-07-03 06:11:39 | Re: [PATCH] introduce XLogLockBlockRangeForCleanup() |
Previous Message | Amit Khandekar | 2014-07-03 05:45:53 | Re: [PATCH] introduce XLogLockBlockRangeForCleanup() |