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

On Wed, Feb 1, 2012 at 11:46 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 31.01.2012 17:35, Fujii Masao wrote:
>>
>> On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>>
>>> On 20.01.2012 15:32, Robert Haas wrote:
>>>>
>>>>
>>>> On Sat, Jan 14, 2012 at 9:32 AM, Heikki Linnakangas
>>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>    wrote:
>>>>>
>>>>>
>>>>> Here's another version of the patch to make XLogInsert less of a
>>>>> bottleneck
>>>>> on multi-CPU systems. The basic idea is the same as before, but several
>>>>> bugs
>>>>> have been fixed, and lots of misc. clean up has been done.
>>>>
>>>>
>>>>
>>>> This seems to need a rebase.
>>>
>>>
>>>
>>> Here you go.
>>
>>
>> The patch seems to need a rebase again.
>
>
> Here you go again. It conflicted with the group commit patch, and the patch
> to WAL-log and track changes to full_page_writes setting.

After applying this patch and then forcing crashes, upon recovery the
database is not correct.

If I make a table with 10,000 rows and then after that intensively
update it using a unique key:

update foo set count=count+1 where foobar=?

Then after the crash there are less than 10,000 visible rows:

select count(*) from foo

This not a subtle thing, it happens every time. I get counts of
between 1973 and 8827. Without this patch I always get exactly
10,000.

I don't really know where to start on tracking this down.

Cheers,

Jeff