Corrupted WAL production possible in gistxlog.c
Yoichi HIRAI <yh@is.s.u-tokyo.ac.jp>
From: Yoichi Hirai <yh@is.s.u-tokyo.ac.jp>
To: pgsql-hackers@postgresql.org
Cc: yh@is.s.u-tokyo.ac.jp
Date: 2009-12-24T06:04:26Z
Lists: pgsql-hackers
Attachments
- gistxlog_fix_xlinfo.patch (text/x-patch) patch
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 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