On Tue, Feb 21, 2012 at 8:19 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Sat, Feb 18, 2012 at 12:36 AM, Heikki Linnakangas > <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers