Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <D0C6BEC4-7185-42DE-B77A-7EC20DFD2A87@apache.org>
From: Damien Katz <damien@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <7fe7e0900902270607r1c881ddej696440f5f8fc2b14@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Segmentation fault on PUT
Date: Fri, 27 Feb 2009 09:22:07 -0500
References: <7fe7e0900902270036y6a9511b1oaac662b9e51f4d6d@mail.gmail.com>
 <05A8FFE6-309E-4B98-B179-D3FB2222111A@apache.org>
 <7fe7e0900902270607r1c881ddej696440f5f8fc2b14@mail.gmail.com>

If you purge the doc it will discard the revision history. See the  
test suite for the purge test to see how to use it.

Purge has caveats. Purge doesn't work with replication at all, the  
purge isn't replicated, the doc is simply "forgotten". You cannot  
purge anything during a compaction. If you do 2 purges in a row  
(before the views have a chance to refresh), all the db's view indexes  
must be rebuilt from scratch (In your case, with 51 docs, this doesn't  
really matter).

-Damien


On Feb 27, 2009, at 9:07 AM, Tim Somers wrote:

> Thanks for the answer, I hope the work you mentioned can solve some  
> things.
> In the mean while, can my problem be solved if from time to time I  
> delete
> the document and recreate another with the same id and contents? I'm  
> not
> using any replication (yet) by the way.
>
> Tim
>
>
> On Fri, Feb 27, 2009 at 2:56 PM, Damien Katz <damien@apache.org>  
> wrote:
>
>> It's probably the "lots of updates" that's causing the problem.  
>> CouchDB
>> tracks a revision history of each doc, indefinitely. If the list  
>> gets longer
>> than can be held in memory, you get errors. (that it is a seg fault  
>> rather
>> than an recoverable error is a bug in the erlang vm, IMO).
>>
>> There is revision stemming work that's on the way, that addresses  
>> this
>> exact problem (though with caveats for replication).
>>
>> -Damien
>>
>>
>>
>>
>> On Feb 27, 2009, at 3:36 AM, Tim Somers wrote:
>>
>> Hi all,
>>>
>>> I've been using couchdb in combination with py-simplecouchdb since a
>>> couple
>>> of weeks now on a small dataset (only 51 docs) with lots of updates.
>>> Yesterday I checked out the latest update from svn, and left my
>>> application
>>> running all night. This morning, the couchdb process had closed.
>>> After restarting it, everything seems to be running fine for read  
>>> access,
>>> but on an update of any document, I get this error:
>>> [debug] [<0.64.0>] 'PUT' /heasys/alert_3505_nomessages {1,1}
>>> Headers: [{'Accept',"application/json, text/javascript, */*"},
>>>        {'Accept-Charset',"ISO-8859-1,utf-8;q=0.7,*;q=0.7"},
>>>        {'Accept-Encoding',"gzip,deflate"},
>>>        {'Accept-Language',"en-us,en;q=0.5"},
>>>        {'Connection',"keep-alive"},
>>>        {'Content-Length',"239"},
>>>        {'Content-Type',"application/json; charset=UTF-8"},
>>>        {'Host',"localhost:5985"},
>>>        {'Keep-Alive',"300"},
>>>        {'Referer',"
>>> http://localhost:5985/_utils/document.html?heasys/alert_3505_nomessages
>>> "},
>>>        {'User-Agent',"Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 
>>> 1.9.0.6)
>>> Gecko/2009020409 Iceweasel/3.0.6 (Debian-3.0.6-1)"},
>>>        {"X-Requested-With","XMLHttpRequest"}]
>>> Segmentation fault
>>> No difference in the error except for the headers whether I test  
>>> it with
>>> my
>>> application or the futon interface.
>>>
>>> Any ideas, anyone?
>>>
>>> Thanks
>>> Tim Somers
>>>
>>
>>