Hello, I was reading GiST core codes when I found an XLogInsert() call that can produce a corrupted WAL record. == Summary == There is an execution path that produces a WAL record whose xl_info indicates XLOG_GIST_PAGE_UPDATE while the record actually contains a gistxlogPageSplit structure. == Details == (Line numbers are for HEAD as of Wed Dec 23 19:42:15 2009 +0000.) The problematic XLogInsert() call is on gistxlog.c, line 770: recptr = XLogInsert(RM_GIST_ID, XLOG_GIST_PAGE_UPDATE, rdata); where the last argument rdata has a pointer assigned either on line 741 or on line 752. When rdata comes from formSplitRdata() at line 741, rdata contains a reference to a gistxlogPageSplit structure. This is inconsistent with the second argument XLOG_GIST_PAGE_UPDATE. == Importance == I think this poses possible data loss under multiple consecutive crashes. == Fix == I attach a simple patch (for HEAD as of the datetime above) that, I suppose, prevents the corrupted WAL production. I would be glad if you liked it. Please note that the execution path exists at least in current HEAD, REL8_2_STABLE and the branches in between. Sincerely, Yoichi Hirai Dept. of Computer Science, The University of Tokyo
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера