couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <>
Subject Re: [jira] Created: (COUCHDB-1004) list_to_existing_atom is too restrictive as used by couch_rep
Date Sun, 02 Jan 2011 13:48:31 GMT

   perhaps I just heard wrong or misinterpreted what was said in the chat room. It did seem
unusual that calling list_to_atom("foo") twice would add more than one atom. So just reverting
the call back in couch_rep:dbinfo should suffice to fix this as it's internal. Thanks,


On Jan 2, 2011, at 8:26 AM, Klaus Trainer wrote:

> As far as I can remember, the motivation behind list_to_existing_atom
> was not the fact that list_to_atom pollutes the atoms table during
> normal operation. However, it won't prevent atom table pollution when
> something goes wrong or somebody goes malicious (i.e., DoS attack).
> I've just looked it up for you, the exact description is here:
> - Klaus
> On Sun, 2011-01-02 at 08:06 -0500, Bob Dionne (JIRA) wrote:
>> list_to_existing_atom is too restrictive as used by couch_rep
>> -------------------------------------------------------------
>>                 Key: COUCHDB-1004
>>                 URL:
>>             Project: CouchDB
>>          Issue Type: Bug
>>          Components: Replication
>>         Environment: erlang
>>            Reporter: Bob Dionne
>>            Priority: Minor
>> We'd like to additional information to db_info in BigCouch, such as the Q and N constants
for a given database. This causes replication to fail when replicating from BigCouch to CouchDB
due to the use of list_to_existing_atom in couch_rep:dbinfo(...
>> The claim is that list_to_atom pollutes the atoms table, however superficial testing
indicates this is not the case, list_to_atom when called repeatedly seems to work fine. If
this is true then consider reverting list_to_existing_atom back to list_to_atom.

View raw message