On Thu, Mar 15, 2012 at 5:52 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> When all those changes are put together, the patched version now beats or
> matches the current code in the RAM drive tests, except that the
> single-client case is still about 10% slower. I added the new test results
> at http://community.enterprisedb.com/xloginsert-scale-tests/, and a new
> version of the patch is attached.
When I ran pgbench with v18 patch, I encountered the following PANIC error:
PANIC: space reserved for WAL record does not match what was written
To investigate the cause, I applied the following changes and ran pgbench again,
------------------------
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index bfc7421..2cef0bd 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -1294,7 +1294,7 @@ CopyXLogRecordToWAL(int write_len, bool
isLogSwitch, XLogRecord *rechdr, }
if (!XLByteEQ(CurrPos, EndPos))
- elog(PANIC, "space reserved for WAL record
does not match what was written");
+ elog(PANIC, "space reserved for WAL record does not
match what was written, CurrPos: %X/%X, EndPos: %X/%X",
CurrPos.xlogid, CurrPos.xrecoff, EndPos.xlogid, EndPos.xrecoff); } else {
------------------------
then I got the following:
PANIC: space reserved for WAL record does not match what was
written, CurrPos: C/0, EndPos: B/FF000000
So I think that the patch would have a bug which handles WAL boundary wrongly.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
