Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)

On Thu, Mar 15, 2012 at 5:52 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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