Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Date
Msg-id CAHGQGwGYQ-hOFDncgDqs104E9-8w90bpHj+WArU0DOv8vdGJFA@mail.gmail.com
Whole thread Raw
In response to Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
List pgsql-hackers
On Tue, Feb 21, 2012 at 8:19 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Sat, Feb 18, 2012 at 12:36 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Attached is a new version, fixing that, and off-by-one bug you pointed out
>> in the slot wraparound handling. I also moved code around a bit, I think
>> this new division of labor between the XLogInsert subroutines is more
>> readable.

When I ran the long-running performance test, I encountered the following
panic error.
   PANIC:  could not find WAL buffer for 0/FF000000

0/FF000000 is the xlog file boundary, so the patch seems to handle
the xlog file boundary incorrectly. In the patch, current insertion lsn
is advanced by directly incrementing XLogRecPtr.xrecoff as follows.
But to handle the xlog file boundary correctly, we should use
XLByteAdvance() for that, instead?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: REASSIGN OWNED lacks support for FDWs
Next
From: Greg Smith
Date:
Subject: Re: Displaying accumulated autovacuum cost