Re: 9.4 checksum error in recovery with btree index
От | Jeff Janes |
---|---|
Тема | Re: 9.4 checksum error in recovery with btree index |
Дата | |
Msg-id | CAMkU=1zGupr8ML4h58qC+jgJMxCuAM-vMtAQLBGUQPTyUqBQrQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.4 checksum error in recovery with btree index (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: 9.4 checksum error in recovery with btree index
|
Список | pgsql-hackers |
On Mon, May 19, 2014 at 3:32 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
Okay, thanks, committed.On 05/18/2014 06:30 AM, Jeff Janes wrote:On Saturday, May 17, 2014, Heikki Linnakangas <hlinnakangas@vmware.com>
wrote:The seems to have fixed it.
Your torn-page generator seems to be very good at finding bugs - any chance you could publish it?
What would be a good way of doing that? Mostly I've just been sharing it on google drive when I find something. Should I fork the mirror from github (https://github.com/postgres/postgres)? Forking the entire codebase just to have a 200 line patch and 2 driving scripts seems excessive, but I guess that that is the git philosophy. Or is there a better way than that?
This is a recent one on google drive here:
It is the one that I used for testing gin indexes, not the one that was at issue here.
I wonder if it could've caught the similar mishap in the clearing of the incomplete-split flag. I think you'd a checkpoint to begin in the very narrow window between splitting a page and inserting the parent pointer.
I could re-introduce that bug and see if it would be found, but I've already moved on to testing fk (which is what I was trying to test when I found the btree bug) and I don't think I preserved the original code, so I don't know how effective it would be as a test. (I guess that speaks in favor of using git to record the source code as of each interesting point.)
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: