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

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Дата
Msg-id CAHGQGwGYQ-hOFDncgDqs104E9-8w90bpHj+WArU0DOv8vdGJFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)  (Jeff Janes <jeff.janes@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: REASSIGN OWNED lacks support for FDWs
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Displaying accumulated autovacuum cost