| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
| Date: | 2012-02-22 01:34:01 |
| Message-ID: | CAHGQGwGYQ-hOFDncgDqs104E9-8w90bpHj+WArU0DOv8vdGJFA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 21, 2012 at 8:19 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, Feb 18, 2012 at 12:36 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2012-02-22 04:27:58 | Re: Displaying accumulated autovacuum cost |
| Previous Message | Tom Lane | 2012-02-22 00:30:39 | Re: REASSIGN OWNED lacks support for FDWs |