On Thu, Mar 15, 2012 at 5:52 AM, Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers