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 include a simple patch (for HEAD as of the datetime above) that, I suppose, prevents the corrupt 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
gistxlog_fix_xlinfo.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
