Klaus,
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,
Bob
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:
> https://issues.apache.org/jira/browse/COUCHDB-829
>
>
> - 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: https://issues.apache.org/jira/browse/COUCHDB-1004
>> 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.
>>
>
>
